Últimas actualizações de eventos

Sexta edição, lá vamos nós!

Publicado em

Com muita empolgação anunciamos que nossa sede, segunda maior do Brasil, estará aberta pela sexta edição para recepcionar os jammers participantes da Global Game Jam 2017! Um encontro indie pra galera se divertir, conhecer novas pessoas e produzir games!

As inscrições já estão abertas!

Anúncios

Parceria Lends Club

Publicado em

Logo Centro Home

A quinta edição da GGJ sediada na UNISINOS Porto Alegre contará com apoio da Lends Club, primeira tabuleiria da cidade.  O objetivo é fomentar a produção de jogos analógicos na sede e para isso o melhor jogo analógico criado na sede UNISINOS vai receber:

  • 1 cópia do jogo “O Ataque dos Tubarões-Vampiros”
  • 1 Camiseta Exclusiva Lends Club
  • 1 Free Pass de um dia, para cada desenvolvedor da equipe.

Além disso, durante o evento serão sorteados 6 Free Pass de um dia entre todos os participantes que estiverem trabalhando presencialmente na sede.

Dada largada para quinta edição

Publicado em

Com muito orgulho e empolgação anunciamos que nossa sede estará aberta pela quinta edição para recepcionar os jammers participantes da Global Game Jam 2016!

As inscrições já estão abertas!

Drops de Sabedoria Indie

Publicado em

Estamos lançando hoje o e-book gratuito Drops de Sabedoria Indie contendo as lições aprendidas pelos jammers que participaram da nossa sede de 2012 a 2014. O conteúdo foi gerado pelos participantes, as lições organizadas por João Ricardo Bittencourt e a editoração gráfica feita pelo Júlio Matos.

Além das lições existem dois post mortems dos jogos Happinness e Exodus produzidos na GGJ 2014.

Abra o livreto aleatoriamente e deixe uma pérola iluminar seu processo de desenvolvimento!

Download do e-book (2,2 Mb)

Let’s go!

Publicado em Atualizado em

A UNISINOS irá sediar novamente a Global Game Jam no campus Porto Alegre. Esse ano a jam irá ocorrer nos dias 23, 24 e 25 de janeiro! Faça tua inscrição até o dia 20/01 pois temos vagas limitadas e não aceitaremos inscrições no local.

Até o presente momento já temos confirmado o apoio da aceleradora Estarte.me.

Postmortem: Happiness

Publicado em Atualizado em

Por Sharbel Freiberger – FIREhurricane

Apesar de já termos participado de algumas GGJs e várias Ludum Dares, tanto em equipe quanto solo, ainda assim todo evento sempre é uma surpresa. Existe alguns padrões de fatos que acontecem em todos eventos, e no geral sempre coisas boas. Nessa última GGJ por exemplo, já chegamos com algumas definições estabelecidas: quem faria o que, e o que usaríamos para desenvolver o jogo.

Unity3D era uma certeza. Ela é uma ferramenta muito boa, e eventos assim são ótimos para praticar e aprofundar o conhecimento em desenvolvimento. De fato foi isso realmente ocorreu no evento, já que fomos ao evento sem conhecer as novas atualizações da Unity para jogos 2D, e na programação tivemos problemas com algumas coisas que nunca tínhamos usado no desenvolvimento como o sistema de animação e os novos scripts de física, e isso gastou mais tempo do que prevíamos.

Quando recebemos o tema, tivemos um brainstorm muito rápido: como trabalhamos juntos a um tempo, já cometemos erros comuns como bolar projetos megalomaníacos, ou tentar elaborar um sistema de jogo muito complexo sem ter um conhecimento mínimo para usar uma mecânica similar. Escolhemos então o mais simples possível: Runner. Mas o tema permitia uma viagem de idéias maior, e foi quando eu pensei que seria interessante se no runner o jogador não tivesse que jogar o jogo como um Runner comum, assim ele poderia visualizar o “outro mundo”. Wallace havia pensado mais na parte da história, pois a idéia era não ter uma história muito óbvia, como acreditávamos que a maioria seria.

Como nosso time era composto por dois programadores a arte poderia ser um trabalho, porém o Wallace havia feito um curso recente de Pixel Art e ficou responsável pela arte, usando o tempo para colocar em prática tudo que tinha aprendido no curso. O curto espaço de tempo sempre é um problema, pois você sempre deseja fazer alguma coisa a mais, ou deixar seu jogo o melhor possível, mas cortar extras e fazer um escopo pequeno é essencial para chegar até o final e terminar o jogo nesse prazo. Keep It Simple.

Como são apenas 48 horas, você começa a restringir um pouco de sono e tentar se organizar o máximo possível pra conseguir fazer mais coisas. Isso é bem natural, principalmente quando se tem pouca experiência ou se tem um problema muito sério com o projeto. Mas também sempre é bom largar tudo um pouco e dar uma parada pra limpar a cabeça. O Wallace chegou a fazer isso algumas vezes entre um desenho e outro, e eu como estava na programação tendo dificuldades, quase que não fiz isso.

Uma das maiores vantagens da GGJ é você poder falar pessoalmente com as outras pessoas que estão fazendo os jogos, e ver o que eles estão fazendo. No nosso caso, uma coisa interessante pela qual nunca havíamos passado era a de ficar em uma das salas com outros dois grupos. Isso nos deixou mais próximos, e eventualmente pedíamos comida juntos, efetuávamos testes no jogos e opinávamos.

Isso tanto durante o desenvolvimento quanto na apresentação final, que você vê como ficou o final de todas equipes.

O Que Deu Certo?

  • Escopo do jogo: Por já termos feito algumas LDs e GGJs, já tínhamos noção do tamanho que deveria ser o projeto, o que fazer, o que cortar, como manter um mínimo jogável e a partir dali começar a implementar mais no jogo.
  • Separação de tarefas: O Wallace já estava bem “aquecido” como ilustrador, mas precisou treinar animações também. Eu consegui desenvolver uma mecânica bem interessante no qual utiliza inclusive o novo sistema de animação da Unity, coisa que eu nunca havia feito.
  • Música: Muitas pessoas que jogaram o jogo gostaram bastante da parte da transição, tanto dos gráficos, mas principalmente da música. Houve um cuidado do Wallace ao selecionar as músicas, pois ele selecionou músicas que tivessem o mesmo BPM e em um valor alto (170 no caso).
  • Gráficos “Kawaii”: Recebemos esse feedback que mostrava que os gráficos deram certo. Com o tema escolhido e o brainstorm definido foi possível imaginarmos várias possibilidades de cenários no momento que o jogador estava dopado.
  • Sacada Surpresa: O efeito da surpresa ao notar que o objetivo do jogo é desviar das moedas era sempre de encher os olhos de quem jogava. Um dos feedbacks pegou mais de 200 moedas e perguntou quantas moedas ainda precisava pegar. Ao descobrir que não era pra pegar as moedas e ver a transição, soltou um grito de surpresa, dizendo o quanto o jogo era bom (o termo usado não foi “bom”).

O Que Deu Errado?

  • Engine: Tivemos problemas principalmente por não termos conhecimento nas novas ferramentas da Unity. Isso nos travou por mais tempo do que gostaríamos, e me custou umas horas nas quais eu poderia ter dormido.
  • Animações: Pelo Wallace, uma das maiores dificuldades foi fazer as animações. Ele havia feito uma em Pixel Art dias antes do evento. Ele conseguiu aprender bem apenas no domingo.
  • Evolução dos desenhos: É possível notar nos desenhos uma certa mistura de traços. Como todo ilustrador em início de carreira, o Wallace ainda não tinha encontrado um padrão de desenho.

O Que Fazer Agora?

Atualmente o jogo esta disponível no Game Jolt, e estamos estudando uma forma de torna-lo um Runner com certa objetividade. A idéia é continuar a história após ele sair do transe dos remédios. Vamos deixando as pessoas informadas sobre no site da Game Jolt.

Postmortem: Exodus

Publicado em

Por Israel Steinmetz – Double Cheddar Team

Exodus foi um projeto feito mim e mais dois amigos para a Global Game Jam de 2014 no campus da Unisinos. A ideia de participar da Jam veio como forma de testar nossas habilidades e ver se conseguiríamos trabalhar em equipe. Quando montamos o time, decidimos os papéis de cada um baseado nas suas habilidades e no fim, tínhamos um programador, um artista e um gerente de projeto. Não sabíamos muito o que esperar da GGJ, já que esta iria ser a nossa primeira.

Logo ao chegar o evento, sem saber, um dos fatores que nos ajudou bastante foi definido; conseguimos uma sala, que por algum motivo nenhum outro time quis. Uma sala vazia, com espaço para desenvolver com calma, pensar, conversar e mesmo se entreter. Foi um fator essencial para as condições físicas e psicológicas do time. Ter a liberdade para por músicas nos alto-falantes e um ambiente descontraído foi benéfico para a moral do time. Quando o cansaço apertava e o rendimento diminuía, esses pequenos momentos de diversão ajudavam a equipe. Um outro pequeno detalhe que creio ter contribuído positivamente foi o layout do ambiente de trabalho. Como éramos três, dispusemos as áreas de trabalho do artista ao lado do programador, permitindo maior comunicação entre eles, já que o desenvolvimento requer muita troca de informação de ambas as partes, enquanto eu me posicionei perto dos quadros brancos, podendo ver o resto do time ao mesmo tempo que geria o projeto.

Tudo na Jam conta como fator de risco do jogo. Tempo curto, complexidade, diversão, qualidade. Por isso, no momento de criar o conceito do jogo fizemos um brainstorm levando em conta parte desses fatores. Na realidade foram feitos três brainstorms para não nos fecharmos numa só ideia e forçar a criatividade. Nosso primeiro conceito foi sobre um jogo extremamente metafórico e abstrato. O segundo foi a ideia que deu origem ao Exodus, e o terceiro consistia em outro plataformer, só que a mecânica principal sendo diferente, envolvendo ponto de vista do jogador ao se mexer para frente ou para trás. Escolhemos o conceito que seria do Exodus pois recebemos feedback externo, e vimos que seria interessante valorizar o gameplay, ao invés de fazer algo mais conceitual, e pensamos que a mecânica dessa segunda ideia era mais divertida e interessante que a da terceira. Feedback foi essencial, bem como sair da zona de conforto de uma só ideia no brainstorm.

Possuindo uma ideia, ambiente e o time pronto o que faltava agora era a espinha dorsal do desenvolvimento, a organização. Por exemplo, tanto arte como programação foram bastante discutidos com antecedência, para evitar improvisos ao decorrer das 48 horas. Como gerente do projeto, apliquei Scrum para guiar o time durante o desenvolvimento. Defini com eles as funcionalidades que o jogo deveria ter, e deleguei as funções para cada um. Cada tarefa era dada num intervalo de duas horas, as Sprints (apesar de termos feitos Sprints de três e também de uma hora e meia quando necessário). Cada tarefa ficava anotada num post-it, que era organizado num quadro branco dividido em três colunas: PB, Doing, Undo e Done. PB eram aonde ficavam as tarefas, os Products Backlogs. Doing, Undo e Done eram respectivamente as tarefas que estavam sendo realizadas na Sprint, as que tinham que ser refeitas e as terminadas. O Scrum nos foi útil por diversas razões: Dava feedback visual do andamento do jogo, tínhamos definido quando o jogo acabaria (uma das coisas mais importantes!), permitia administrar bem as horas de trabalho e de descanso, assim não sobrecarregava o time. Dentre tudo isso, obviamente a boa convivência e dedicação do time são essenciais. Café ajuda bastante.

Plataforma: Windows

Tamanho do time: 3 (1 programador, 1 ilustrador, 1 game designer/gerente de projeto)

Ferramentas de desenvolvimento: Wacom CTL-460 Bamboo, Adobe Photoshop (Trial de 30 dias) e a Unity3D.

Som:  usamos efeitos de bibliotecas públicas de som e a música é do Dan-O (licença aberta)