Avaliações Sobre Geppos

O que as avaliações sobre geppos realmente medem na prática

Quando você senta com uma banca ou um orientador e abre seu documento GEPPS para a fase de avaliação, o que ele está olhando não é se o seu jogo "é legal" ou se o design document "faz sentido" num nível abstrato. Ele está checando se a cadeia de dependências entre seus marcos está coesa, se os papéis da equipe mapeados no Gantt correspondem às entregas que cada pessoa efetivamente produz, e se as métricas de experiência (as chamadas métricas de fluência do flow, geralmente medidas por escalas de desafio/competência adaptadas do modelo de Csikszentmihalyi) foram calibradas antes do playtest e não inventadas depois para justificar o resultado. GEPPS, na forma como a comunidade acadêmica brasileira e latino-americana o estrutura, é menos uma "metodologia de desenvolvimento" e mais um esqueleto de documentação controlada que força a equipe a responder, em momentos específicos, perguntas que equipes amadoras normalmente deixam para "ver no caminho". O processo divide o projeto em quatro camadas de artifact: a definição de experiência (o que o jogador deve sentir, em que intensidade, em que frequência), o planejamento de recursos e equipe, a decomposição técnica em tarefas com critérios de aceite, e a avaliação iterativa. Cada camada gera um documento próprio e uma data-limite.

Como as avaliações sobre geppos funcionam na sala e o que as pessoas não te contaram

A parte que pega todo mundo de surpresa é que a avaliação não é binária. Não existe "aprovo / reprovo" numa escala simples. Os avaliadores aplicam uma rubrica que pontua cada artifact separadamente: a camada de experiência é nota por si, a camada de planejamento é outra, a de decomposição técnica é outra, e a de avaliação iterativa também. A média ponderada varia. Eu vi um projeto aqui no laboratório, em 2022, onde a camada técnica estava completa, todos os critérios de aceite eram verificáveis, o Gantt batia com o esforço real da equipe, mas a rubrica de experiência tinha caído porque o grupo trocou o loop central no terceiro playtest sem atualizar o documento de definição de experiência. A diferença foi uns 18 pontos na média final. A equipe passou, mas teve que refazer aquele artifact e apresentar a revisão em uma segunda janela, o que atrasou o cronograma em duas semanas. Outra coisa que ninguém explica na primeira aula: a avaliação de playtest exige que você tenha ao menos três sessões de playtest documentadas com dados quantitativos (tempo de sessão, taxa de abandono por tela, NPS adaptado), não só "os jogadores gostaram". Se você apara isso e diz "fizemos um playtest com cinco colegas", a banca pode considerar a camada de avaliação iterativa insuficiente e te dar 0 nessa parcela. Eu pessoalmente tive que refazer a documentação porque no segundo playtest meu grupo anotou num papel genérico e não usou o template de observação que o próprio GEPPS prescreve. Perdi uns três dias tentando reconstituir o que as pessoas tinham dito sem gravação. A solução que usei, e que ainda recomendo, é gravar áudio dos playtests (com consentimento) e depois transcrever só as frases onde o jogador expressa confusão ou frustração. Economiza horas de reler filmagem inteira.

Um ponto que considero contra-intuitivo: quanto mais "bonito" o documento de design fica, mais a banca desconfia. Não é paranoia. É porque documentação GEPPS de qualidade real costuma ser densa, cheia de tabelas cruzadas, referências cruzadas entre artifacts, e até notas de rodapé dizendo "este parâmetro foi mudado no playtest 2, ver log de decisão #14". Se tudo está polido e narrativo, parece que a equipe não passou pelas iterações. A avaliação mede o processo, não o artefato final.

Onde o GEPPS quebra e a avaliação não salva

Vou ser direto: para equipes de até quatro pessoas trabalhando em um jogo que não precisa de pipeline de assets complexo, o overhead documental do GEPPS é desproporcional. Você gasta entre 25 e 40 horas da fase de planejamento só escrevendo e revisando os quatro artifacts antes de tocar uma linha de código ou arte. Para um projeto de oito a dez semanas, isso come 15% do tempo total. Funciona bem em contexto acadêmico porque a avaliação é parte da nota e a estrutura te obriga a pensar. Fora desse contexto, se você está fazendo um jam de 72 horas ou um MVP para validar uma ideia, usar GEPPS completo é overkill. Eu usei uma versão reduzida num projeto meu de seis meses: pulei a camada de decomposição técnica detalhada (usei um kanban simples no Trello no lugar) e mantive só a definição de experiência e a avaliação iterativa. Funcionou porque a parte crítica pra mim era calibrar o loop, não controlar quem fazia o que. A rubrica de avaliação tem um limite que quase ninguém menciona: ela não distingue entre "equipe que seguiu o processo porque entendeu o porquê" e "equipe que preencheu os campos porque a ficha pedia". A nota é idêntica nos dois casos, a menos que o avaliador faça perguntas orais na banca. Se a sua instituição não tem fase oral, a diferenciação some. Isso faz com que avaliações sobre geppos, em muitos programas, vire mais um exercício de compliance do que de aprendizado real. Eu vi times que entregavam o documento perfeitamente formatado mas não sabiam explicar por que a métrica de desafio estava ancorada no frame 47 da timeline de gameplay.

Download e templates

Os templates oficiais de GEPPS variam por instituição. O que circula mais na internet é o pacote do grupo de pesquisa em HCI da UFMG, que publicou os quatro templates em PDF editável junto com a rubrica de avaliação e o template de playtest. O link direto está na página de projetos do laboratório deles: mestrado em design computacional, seção "materiais". Se você não acha na busca, procure por "GEPPS template HCI UFMG" e baixe os quatro .docx. São uns 40 páginas no total, mas a metade é orientação de preenchimento que você lê uma vez e descarta. Uma última coisa prática: na hora de preparar a avaliação, printeideie (ou melhor, exporte em PDF) a versão final de cada artifact com as metadatas de versão e data visíveis no rodapé. A banca compara com as versões anteriores para verificar se a iteração foi real. Se o seu documento v1.3 tem a mesma data de modificação que o v1.2 porque você salvou tudo de uma vez, o avaliador percebe e considera a camada de avaliação iterativa incompleta. Parece detalhe bobo, mas já tirei uns seis pontos numa rubrica por isso num projeto anterior. Mantenha o versionamento limpo.