Saiu o ranking dos jogos do Global Game Jam 2010 em Curitiba. Poxa, que legal, no que pode ser considerado a classificação dos melhores jogos, o Aliens and Zombies ficou em 3º lugar dentre os 8 jogos (item Melhor Jogo no Geral). A votação usada no Global Game Jam de Curitiba considera pontos separados sem fazer um esforço de fechar um total significativo, então tem que pegar os itens mais relevantes mesmo. Pessoalmente, esse item é o mais top da lista, então motivos de alegria eu tenho de sobra :D.
Divertido foi a gente ser segundo lugar para Jogo mais Educativo (!?), já que o jogo não tem nada de educativo, por assim dizer :). Mas foi bacana a gente conseguir o segundo lugar como Maior Preocupação com os Detalhes, já que fizemos um esforço para polir a interface gráfica, usando apenas linguagem icônica para evitar textos (explicar o jogo assim não foi fácil), com animações para todos os personagens, efeitos sonoros adequados em cada lugar, etc :).
Agora é esperar o próximo Game Jam :).
Mostrando postagens com marcador programação de jogos. Mostrar todas as postagens
Mostrando postagens com marcador programação de jogos. Mostrar todas as postagens
sexta-feira, 5 de fevereiro de 2010
terça-feira, 2 de fevereiro de 2010
Global Game Jam 2010 - Resumão
O programa do FDS para desenvolvedores de jogos de Curitiba foi longo. Desenvolver um jogo das 17:00h de sexta dia 29 de Janeiro, até às 16:00 de Domingo dia 31, para apresentá-lo na sequência. É exatamente isso o Global Game Jam, que eu não perdi a chance de participar. 48 horas depois e uma boa noite de sono, posso comentar mais detalhes.
Claro, quem acompanha o meu Twitter deve ter recebido todas as novidades e fotos praticamente em "tempo real". O evento consiste em, obviamente, desenvolver um jogo completo nas 48 horas (47 no nosso caso) dentro do tema dado, com as restrições propostas. O tema deste ano foi deception (enganar), com as restrições do nosso fuso horário line, mine e pine (cada fuso horário tem restrições diferentes). Engraçado foi o sujeito que deu a entrevista em Recife dizer que o tema do ano foi "decepção". Dá-lhe falso cognato.

Team Grayscale - da esquerda para a direita, no fundo,
Christian, Diego, Flavia e Bruno, na frente, eu
Formei uma equipe com ex-alunos de ciência da Computação, da época em que eu era professor na PUCPR. Gente finíssima, o Christian, o Diego, a Flavia e o Bruno. O jogo foi de ação top view, chamado Aliens and Zombies (versão Linux e Windows para download), tendo como objetivo enganar os inimigos, já que o jogador não possui armas. Nada extremamente original, mas o jogo saiu bem completo, o que foi uma coisa boa, já que algumas equipes se aventuraram em projetos mais complexos (e não necessariamente originais) que não chegaram nem na metade do caminho.
No final, todo mundo se divertiu pra caramba, com muita história para contar, entregadores com verdadeiras torres inclinadas de pizza perdidos no campus da universidade, café da manhã surpresa e "conquistas secretas", como a pizza especial para os que estavam acordados e trabalhando às 5:00h da manhã. Ano que vem eu vou se tiver de novo.
Enquanto isso, fica o registro em vídeo (720p) do desenvolvimento do jogo.
Para os que acharem legal, uma apresentação (em inglês lesado pelo sono) do jogo e da equipe.
Claro, quem acompanha o meu Twitter deve ter recebido todas as novidades e fotos praticamente em "tempo real". O evento consiste em, obviamente, desenvolver um jogo completo nas 48 horas (47 no nosso caso) dentro do tema dado, com as restrições propostas. O tema deste ano foi deception (enganar), com as restrições do nosso fuso horário line, mine e pine (cada fuso horário tem restrições diferentes). Engraçado foi o sujeito que deu a entrevista em Recife dizer que o tema do ano foi "decepção". Dá-lhe falso cognato.

Christian, Diego, Flavia e Bruno, na frente, eu
Formei uma equipe com ex-alunos de ciência da Computação, da época em que eu era professor na PUCPR. Gente finíssima, o Christian, o Diego, a Flavia e o Bruno. O jogo foi de ação top view, chamado Aliens and Zombies (versão Linux e Windows para download), tendo como objetivo enganar os inimigos, já que o jogador não possui armas. Nada extremamente original, mas o jogo saiu bem completo, o que foi uma coisa boa, já que algumas equipes se aventuraram em projetos mais complexos (e não necessariamente originais) que não chegaram nem na metade do caminho.
No final, todo mundo se divertiu pra caramba, com muita história para contar, entregadores com verdadeiras torres inclinadas de pizza perdidos no campus da universidade, café da manhã surpresa e "conquistas secretas", como a pizza especial para os que estavam acordados e trabalhando às 5:00h da manhã. Ano que vem eu vou se tiver de novo.
Enquanto isso, fica o registro em vídeo (720p) do desenvolvimento do jogo.
Para os que acharem legal, uma apresentação (em inglês lesado pelo sono) do jogo e da equipe.
Marcadores:
2010,
C/C++,
computador,
férias,
programação de jogos
sábado, 5 de dezembro de 2009
Então Você Quer Fazer Jogos?
Se tem uma coisa que é bastante comum, é o sujeito fazer um vestibular e descobrir que o curso era algo completamente diferente do que ele esperava. Uma tirinha do Nerdson, que menciona especificamente "aprender a fazer jogos" e "fazer um curso de computação", exemplifica claramente o caso com grandes chances de acabar em frustração.
A maioria das pessoas que querem fazer um jogo são, na maioria esmagadora, jogadores que se encantam com as imagens na tela. Nada de anormal, a pessoa que vira pintor também se apaixona pela arte vendo trabalhos de terceiros. Só que ao contrário do pintor, que trabalha sozinho e tem uma técnica comum a maioria de seus trabalhos, o jogo é feito por muitas pessoas, com competências bastante diferentes. Cada uma dessas pessoas não produz um pedaço "tangível" do jogo. Ou seja, se você pegar o trabalho de 10% da equipe, você não sai com 10% do jogo. A soma do trabalho para se fazer um jogo é maior do que as partes individuais. Só que ninguém fazendo vestibular hoje sabe disso, nem sabe para qual dos 10% do jogo ele quer contribuir e que ele não pode contribuir em todas as etapas. Pior ainda se o indivíduo usou uma ferramenta do tipo maker, visual, que é uma ferramenta que não tem nada a ver com programação.
Para deixar mais claro, imagine a seguinte situação. Você está jogando pela primeira vez na sua vida uma partida de Super Mario Brothers (uma vez isso deve ter acontecido, então lembre-se da sensação). Em um dado momento o Mario "gigante" pula contra um bloco do cenário e quebra-o como se ele não fosse nada. Ao fazer isso, você vê que o Mario agora pode passar livremente por onde havia o bloco antes. Inclusive, inimigos podem fazê-lo. Um bloco que você podia até andar em cima, agora tinha virado um vazio no espaço. Você:
(a) Fica encantado, pensando nos novos caminho que você pode criar no cenário quebrando os blocos.
(b) Fica encantado, pensando na adequação da animação do bloco sendo quebrado e no efeito sonoro utilizado.
(c) Fica encantado, imaginando como aquela maquininha consegue dizer que ali tinha um bloco, mas que ele quebrou-se e agora o personagem pode passar por ali.
Se você se identificou mais com as duas primeiras respostas, pense duas vezes antes de fazer um curso de computação. Você pode fazer jogos, mas criando o enredo, fazendo a arte, o level design, etc. Para você, pode ser mais eficiente um curso design digital, que vai trabalhar exatamente com o que você se identifica e, melhor de tudo, vai permitir você fazer um jogo com o que você espera que seja fazer um jogo.
Você pode até argumentar "mas eu gosto de mexer com computador". Oras, usar um carro não torna uma pessoa habilidosa em mecânica. Saber usar as ferramentas do computador não é o mesmo que saber criá-las, que é o que um programador faz. Depois você pode dizer "mas eu sou craque em configurar o computador", ou melhor pro pessoal do Linux "eu sei recompilar o kernel". É o equivalente a dizer que você entende de mecânica porque instalou você mesmo os acessórios do seu carro. Configurar um sistema operacional não é o mesmo que escrever um, que é o que programadores (consideravelmente) avançados fazem.
A cartada final para quem responde as letras a e b é de que Shigero Miyamoto era programador. O Chris Crawford era programador. O Peter Molyneux era programador. Exceções não fazem a regra. Existem bons designers que também são bons programadores. Mas em geral, um bom designer é um péssimo programador, e vice-versa. Sem contar que na época do Atari e dos primórdios dos jogos de 8 bits (computador e videogame), só chegava perto de computador um programador, logo, só os poucos que tinham noção de design faziam jogos. Mas a medida que a coisa se profissionalizou, designers tomaram conta do campo da criação, enquanto programadores fincaram o pé no campo da realização.
Aí resta a pergunta indignada de quem respondeu a/b: e porque o sujeito que responde c pode fazer um curso de computação? Porque ele tem pensamento cartesiano. Para ele o mundo é visto como causa e efeito. Para ele, tudo o que ocorre naquele jogo tem uma razão de ser e interessa mais a ele como aquilo foi feito do que aquilo implica no jogo como um todo. É o sujeito que vai tornar possível na "maquininha" a visão do designer.
Um bom programador de jogos é o sujeito que gosta de matemática e conhece as principais técnicas computacionais, para aplicar isso em um jogo. É o sujeito que sabe a relação de um autômato finito e o personagem de um jogo. É quem sabe que um grafo pode servir para criar os caminhos dos personagens do PacMan a representar a hierarquia dos objetos de uma cena 3D. É quem escreve um pequeno compilador para ler do disco as configurações do seu personagem. É quem tem uma aula de álgebra linear e tem um click de como a placa de vídeo projeta os pontos de uma textura em um polígono na tela. É quem conhece a tese de Church-Turing para dizer que certa idéia no jogo não funciona, mas se limitar a certo contexto dá praticamente o mesmo resultado e torna o problema solúvel pelo computador. Enfim, é o cara que pensa em números antes de pensar em imagem na tela.
Claro, muitos que fazem um curso de computação podem argumentar que nenhum professor comente isso em sala. Bobagem. A área de computação é tão vasta que é utopia querer que um curso seja capaz de preparar um aluno especificamente para um setor sem que ele perca uma coisa importante: a habilidade de se adaptar a novas situações. Para quem duvida disso, basta ver anúncios de empresas estrangeiras de jogos no Gamasutra. Todas as posições iniciantes requerem sólida base de ciência da computação (ou de engenharia de computação). Profissionais que saem da universidade com a fundamentação para atuar com a computação como uma ferramenta para atingir um resultado.
Então, para que você não fique indignado como na tirinha do Nerdson, pense bem no tipo de sujeito que você é, porque ele vai dizer o curso que você deve fazer. Se você for o sujeito da resposta c e achar que a faculdade não está ajudando você a entender como o bloco do Mario desaparece, não se preocupe. Use o lado auto-ditata que a faculdade lhe dá e leia bastante, aí você vai agradecer que você aprendeu autômatos, álgebra linear e outras matérias que você não tinha a menor idéia para que serviam.
A maioria das pessoas que querem fazer um jogo são, na maioria esmagadora, jogadores que se encantam com as imagens na tela. Nada de anormal, a pessoa que vira pintor também se apaixona pela arte vendo trabalhos de terceiros. Só que ao contrário do pintor, que trabalha sozinho e tem uma técnica comum a maioria de seus trabalhos, o jogo é feito por muitas pessoas, com competências bastante diferentes. Cada uma dessas pessoas não produz um pedaço "tangível" do jogo. Ou seja, se você pegar o trabalho de 10% da equipe, você não sai com 10% do jogo. A soma do trabalho para se fazer um jogo é maior do que as partes individuais. Só que ninguém fazendo vestibular hoje sabe disso, nem sabe para qual dos 10% do jogo ele quer contribuir e que ele não pode contribuir em todas as etapas. Pior ainda se o indivíduo usou uma ferramenta do tipo maker, visual, que é uma ferramenta que não tem nada a ver com programação.
Para deixar mais claro, imagine a seguinte situação. Você está jogando pela primeira vez na sua vida uma partida de Super Mario Brothers (uma vez isso deve ter acontecido, então lembre-se da sensação). Em um dado momento o Mario "gigante" pula contra um bloco do cenário e quebra-o como se ele não fosse nada. Ao fazer isso, você vê que o Mario agora pode passar livremente por onde havia o bloco antes. Inclusive, inimigos podem fazê-lo. Um bloco que você podia até andar em cima, agora tinha virado um vazio no espaço. Você:
(a) Fica encantado, pensando nos novos caminho que você pode criar no cenário quebrando os blocos.
(b) Fica encantado, pensando na adequação da animação do bloco sendo quebrado e no efeito sonoro utilizado.
(c) Fica encantado, imaginando como aquela maquininha consegue dizer que ali tinha um bloco, mas que ele quebrou-se e agora o personagem pode passar por ali.
Se você se identificou mais com as duas primeiras respostas, pense duas vezes antes de fazer um curso de computação. Você pode fazer jogos, mas criando o enredo, fazendo a arte, o level design, etc. Para você, pode ser mais eficiente um curso design digital, que vai trabalhar exatamente com o que você se identifica e, melhor de tudo, vai permitir você fazer um jogo com o que você espera que seja fazer um jogo.
Você pode até argumentar "mas eu gosto de mexer com computador". Oras, usar um carro não torna uma pessoa habilidosa em mecânica. Saber usar as ferramentas do computador não é o mesmo que saber criá-las, que é o que um programador faz. Depois você pode dizer "mas eu sou craque em configurar o computador", ou melhor pro pessoal do Linux "eu sei recompilar o kernel". É o equivalente a dizer que você entende de mecânica porque instalou você mesmo os acessórios do seu carro. Configurar um sistema operacional não é o mesmo que escrever um, que é o que programadores (consideravelmente) avançados fazem.
A cartada final para quem responde as letras a e b é de que Shigero Miyamoto era programador. O Chris Crawford era programador. O Peter Molyneux era programador. Exceções não fazem a regra. Existem bons designers que também são bons programadores. Mas em geral, um bom designer é um péssimo programador, e vice-versa. Sem contar que na época do Atari e dos primórdios dos jogos de 8 bits (computador e videogame), só chegava perto de computador um programador, logo, só os poucos que tinham noção de design faziam jogos. Mas a medida que a coisa se profissionalizou, designers tomaram conta do campo da criação, enquanto programadores fincaram o pé no campo da realização.
Aí resta a pergunta indignada de quem respondeu a/b: e porque o sujeito que responde c pode fazer um curso de computação? Porque ele tem pensamento cartesiano. Para ele o mundo é visto como causa e efeito. Para ele, tudo o que ocorre naquele jogo tem uma razão de ser e interessa mais a ele como aquilo foi feito do que aquilo implica no jogo como um todo. É o sujeito que vai tornar possível na "maquininha" a visão do designer.
Um bom programador de jogos é o sujeito que gosta de matemática e conhece as principais técnicas computacionais, para aplicar isso em um jogo. É o sujeito que sabe a relação de um autômato finito e o personagem de um jogo. É quem sabe que um grafo pode servir para criar os caminhos dos personagens do PacMan a representar a hierarquia dos objetos de uma cena 3D. É quem escreve um pequeno compilador para ler do disco as configurações do seu personagem. É quem tem uma aula de álgebra linear e tem um click de como a placa de vídeo projeta os pontos de uma textura em um polígono na tela. É quem conhece a tese de Church-Turing para dizer que certa idéia no jogo não funciona, mas se limitar a certo contexto dá praticamente o mesmo resultado e torna o problema solúvel pelo computador. Enfim, é o cara que pensa em números antes de pensar em imagem na tela.
Claro, muitos que fazem um curso de computação podem argumentar que nenhum professor comente isso em sala. Bobagem. A área de computação é tão vasta que é utopia querer que um curso seja capaz de preparar um aluno especificamente para um setor sem que ele perca uma coisa importante: a habilidade de se adaptar a novas situações. Para quem duvida disso, basta ver anúncios de empresas estrangeiras de jogos no Gamasutra. Todas as posições iniciantes requerem sólida base de ciência da computação (ou de engenharia de computação). Profissionais que saem da universidade com a fundamentação para atuar com a computação como uma ferramenta para atingir um resultado.
Então, para que você não fique indignado como na tirinha do Nerdson, pense bem no tipo de sujeito que você é, porque ele vai dizer o curso que você deve fazer. Se você for o sujeito da resposta c e achar que a faculdade não está ajudando você a entender como o bloco do Mario desaparece, não se preocupe. Use o lado auto-ditata que a faculdade lhe dá e leia bastante, aí você vai agradecer que você aprendeu autômatos, álgebra linear e outras matérias que você não tinha a menor idéia para que serviam.
sexta-feira, 7 de agosto de 2009
Aleluia!
Até que enfim, um ambiente de desenvolvimento para Linux legal, que consegue depurar um programa SDL multi-thread sem aperto: Netbeans. Quem diria que o ambiente Java mais caprichado iria, também, ser uma boa pedida para programar C/C++? Projetos organizados de maneira clara e simples, configurações intuitivas, projetos com referência relativa aos arquivos e integração perfeita com o gdb. Falta chão para chegar no Visual C++, mas o suporte a C/C++ dá de 10 no Eclipse (que pra mim já leva de 10 quando o assunto é Java).
Assinar:
Postagens (Atom)