Um dia de trabalho comum como Game Designer

Muita gente quer ser game designer porque acha essa profissão divertida e descolada. Daí imagina que se trata de ficar o dia todo desenhando personagens e situações empolgantes e gargalhando com os amigos no escritório. Ok, isso pode ser verdade em algumas ocasiões. Mas se você quer atuar profissionalmente como game designer tem algumas coisas que precisa saber. Coisas tipo: o que essa pessoa de fato faz, que instrumentos usa e como faz.

Neste texto narrarei um dia de minha rotina de trabalho como game designer no DOT digital group. Não exporei demais os projetos. A ideia é focar no processo de trabalho e não nos produtos. E, vale destacar, se trata da minha rotina. Expressa o meu ambiente de trabalho, mediante o tipo de projetos de games em que eu sou designer. Em outras organizações haverá rotinas bem diferentes. Com toda certeza um game designer na Blizzard ou na TellTale tem outras ferramentas, processos e metas laborais bem diferentes das minhas!

Encare este texto como um inacabado diário de bordo. Vamos a uma lista que relata um dia de trabalho que tive esta semana. Foram 9 horas de trabalho em que tratei de pontos de dois projetos diferentes. Três momentos se destacam: o início de um projeto (que chamarei de projeto-1), e a gestão de projetos e testes (do projeto-2).

A – O Início do Projeto-1

 

A.1 – Anúncio do Game Producer

O Game Producer (ou “produtor”) é a figura gerencial e, quase sempre, comercial da equipe. Preferencialmente é alguém que entende muito de games e também da mecânica da indústria (e como lidar com clientes). O meu Game Producer começou aquele dia me avisando que iríamos começar um novo projeto. Em algumas horas teríamos uma reunião com um cliente que quer um jogo. Explicou o escopo do projeto, orçamento e cronograma. De posse dessas informações fui atrás, no Google, de jogos parecidos com aquele que desenvolveríamos. Afinal, revisões ajudam e muito na criatividade, viu? Também fui checar o portal do cliente e tudo que precisava saber sobre ele para entender suas necessidades.

Liçãozinha #1: revisão “bibliográfica” ajuda na criatividade em games sim! Use e abuse das referências.

Liçãozinha #2: você projeta para clientes, não para si mesmo. Foco no usuário final e também no cliente que paga.

 

A.2 – Conversa no skype com o cliente-pagante

A conversa com o cliente-pagante começou textualmente no Skype. Na imagem ao lado você pode ler uma parte da comunicação em que falamos de cenários que aparecerão no jogo. Ele estava me explicando o que quer e o que precisa. Essas falas dele seriam tratadas por mim até virarem requisitos bem especificados.

Logo consideramos melhor passar para uma videoconferência. É sempre melhor ver e ouvir o cliente-pagante quando ele diz o que quer e o que precisa: mais informações e pistas surgem assim.

Essa primeira comunicação com o cliente-pagante durou 50 minutos.

Liçãozinha #3: Adore conversar com pessoas. Seja bom ouvinte, faça perguntas inteligentes para mantê-las falando coisas relevantes e parta da ideia de que você precisa de MUITOS dados para estabelecer os requisitos corretos.

 

A.3 – Criar documentação

Logo após a conversa com o cliente-pagante, comecei a documentar tudo. Isto é, criar o “Game Design Document”. Para os projetos em que participo funciona assim: depois do GDD estar pronto ele é enviado para o Game Producer, que checa os detalhes comerciais e custos; o Game Producer manda pro cliente-pagante, que pode solicitar mudanças; e o GDD final volta pra mim, sendo o guia do escopo do projeto.

O GDD final explica tudo que virá a ser o jogo. Ele determina inclusive métricas para checar a qualidade do jogo (Quanto mais ele cumprir os requisitos inicialmente consensados, mais qualidade tem). No GDD há especificações sobre objetivos do jogo, suas regras, mecânica, o que o jogador precisa fazer (e porque isso é divertido), interface, o que ele deve proporcionar ao cliente-usuário. Para escrever um é preciso uma boa revisão de jogos análogos. Estudar referências ajuda muito, como já disse.

Costumo criar o GDD no GoogleDOC. Assim dá para compartilhar com o Game Producer e o cliente-pagante, que podem tecer comentários ou mesmo alterar o texto. O GoogleDOC tem essa vantagem, mas ele tem um problema. Não tem um controle de versão. Isto é, as mudanças realizadas no texto não ficam registradas de modo que dê para resgatar todas. Em todo caso, para os projetos que faço, a vantagem do compartilhamento compensou essa desvantagem. Há quem prefira fazer um Wiki e compartilhar a edição dele com o cliente. Mas isso demanda um cliente que entenda o mínimo dessas coisas (o que é um tanto raro).

Pois bem… O Game Design Document ficou muito longo. Por isso o Game Producer pediu para eu resumi-lo em uma apresentação tipo slideshow (Feita no Powerpoint). Ela ficou bem visual e com apenas 12 slides. Foi essa apresentação que o cliente-pagante viu e não o documento de design.

B – Gestão do Projeto-2

 

B.1 – Uso do Trello

Fiquei a manhã toda e o início da tarde focado no início do Projeto-1. Mas ainda havia tarefas a fazer do Projeto-2, iniciado há semanas atrás. E essas tarefas estavam aglutinadas todas em um só lugar: em um quadro no Trello.

Falemos dessa fantástica ferramenta que é o Trello, então. Ele é genial porque se baseia numa metáfora bastante intuitiva:

1. cada projeto vira um “quadro”, isto é, um conjunto de colunas de post-its;
2. as tarefas necessárias para realizar um projeto se acumulam em uma pilha (o “backlog”, algo como “pilha acumulada”). Cada tarefa vira um cartão endereçado a alguém e com informações sobre o que precisa ser feito e (idealmente) como deve ser feito;
3. o cartão de tarefa deve ser trocado de coluna simbolizando uma mudança de status. Assim, pode existir uma coluna “Fazendo”, outra “Rejeitados”, outra “Para entregar no dia tal”, outra “Sugestões para futuros projetos” e por aí vai;
4. o quadro do projeto acaba quando o “backlog” estiver vazio e nada mais precisa ser acrescentado. Ou seja, todas as tarefas estão “feitas” (algumas podem estar na coluna de rejeições, bom, você entendeu, né?).

A medida que os cartões de tarefa vão mudando de coluna você enxerga a realização de metas. Claro que é bem mais complexo que isso. Envolve metodologia bem caudalosa. Se quiser saber mais sobre ela pesquise por “Scrum”.

 

B.2 – Integração com a equipe

Mas nem só de Trello vive a gestão de projetos. Tem a parte burocrática de criar cartões de tarefas, mas quem decide quando um cartão deve ser criado? E como decidir se ele deve sair da coluna de “Para entregar dia 2” para a coluna de “Ideias rejeitadas”?

Para isso o game designer atua como coordenador de equipe. Deve trocar ideias, conversar, se integrar com os desenvolvedores e também com os designers de audiovisual. Apenas em um ambiente de cooperação na equipe é que flui informação para realizar um projeto de game.

Passamos uns 20 minutos definindo mudanças nas cartas de tarefas do Projeto-2. Várias trocaram de coluna. A maioria indo de “Fazendo” para “Feito”. Ótimo, hein?

A maior parte das reuniões costumo fazer em pé. Assim mantemos a agilidade.  Nesse dia um programador me lembrou as regras do Desenvolvimento Ágil, especialmente sobre como usar o Trello corretamente. Também definimos diversos detalhes de Design Visual (ilustrações e personagens em 3D também), efeitos sonoros (baixaríamos alguns free da internet) e da programação do jogo (no caso, sobre o algoritmo de regras, que precisava ser melhor descrito para os desenvolvedores implementarem no código). 

 

C – Testes do Projeto-2

Uma das cartas de tarefa que estavam no Trello do Projeto-2 era endereçada a mim. Dizia: “Fazer o balanceamento”. (Ah, já falei de balanceamento aqui, lembram?).

 O que importa é que passei as duas horas finais da tarde balanceando o game do Projeto-2. A curva de aprendizagem estava inadequada e algumas recompensas estavam caras demais. Nada como rodar simulações no Excel para checar isso!

 

Comentários Finais

Esse texto, como disse no início, é apenas um diário inacabado de bordo. Os dois projetos mencionados continuaram (um deles acabou semana passada). A ideia era só mostrar o dia-a-dia deste game designer aqui para vocês verem que nem sempre essa profissão envolve nerds discutindo Game of Thrones ou lendo HQs. Também há demanda por conhecimentos em lógica, programação, gestão e sem falar, claro, em criatividade focada em resultados para o projeto (não qualquer criatividade tresloucada).

Não expressei aqui tudo que um game designer faz. Nem sequer falei metade do que eu faço como game designer, na verdade. Se vocês gostaram da ideia do diário de bordo, deem um like e/ou peçam por mais nos comentários. Obrigado !