Programador e designer de videojogos — tarefas, uma a uma

Conceber mecânicas, missões e puzzles

Os modelos de linguagem conseguem listar ideias de mecânicas e puzzles a pedido, mas essas ideias vêm de recombinar jogos que já existem, e o difícil não é produzir uma ideia: é saber se é divertida, o que só se vê quando as pessoas jogam. Um design também tem de se ajustar ao orçamento da equipa, ao motor e à identidade do jogo, e alguém tem de responder por ele perante o diretor criativo e a editora. Os estúdios têm poucas razões para entregar esse juízo a uma ferramenta, por isso a ferramenta alimenta o brainstorming e é o designer que continua a escolher.

Isto diz quem decide, não quantos designers um estúdio precisa: se as ferramentas permitirem a cada designer explorar ideias mais depressa, uma equipa pode manter a dimensão e fazer mais, ou encolher. Evidência que o mudaria: um jogo comercial lançado cujas mecânicas centrais foram escolhidas por um sistema generativo, com os designers apenas a rever, ou estúdios a cortar funções de design e a apontar essas ferramentas como motivo.

Equilíbrio e testes de jogo

Partes disto foram automatizadas muito antes dos modelos de linguagem: os painéis de telemetria mostram onde os jogadores desistem, e há scripts que simulam combates e economias. Os agentes treinados para jogar um jogo conseguem agora disputar muitas partidas e explorar níveis mais depressa do que os testadores humanos, o que revela cedo desequilíbrios e exploits. O que não conseguem relatar é como o jogo se sente — se um pico de dificuldade é frustrante ou gratificante —, por isso o designer continua a observar jogadores reais, decide o que mudar e responde por isso quando o jogo é lançado.

Afinar mais depressa encurta o trabalho sem dizer quem perde as horas: os grupos de teste externos e as funções júnior de afinação têm mais probabilidade de o sentir do que o designer principal. O juízo mudaria se os estúdios lançassem alterações de equilíbrio decididas por agentes automáticos sem a aprovação de um designer, ou substituíssem as sessões com jogadores reais por sessões simuladas.

Protótipos e maquetas

É aqui que a tecnologia chega com mais força ao trabalho diário. Os assistentes de código escrevem scripts do motor, código de ligação da interface e lógica de jogo comum a partir de uma descrição, e os geradores de imagem e de 3D produzem depressa arte provisória e ambientes aproximados, por isso um protótipo que antes precisava de uma pequena equipa pode muitas vezes ser construído por uma só pessoa. Um protótipo continua a ter de correr em tempo real no hardware de destino, o código gerado falha de maneiras que só quem percebe o motor consegue encontrar, e o que o protótipo deve provar continua a ser decidido por quem o constrói.

Aumentar ainda pode significar menos pessoas: se um programador consegue prototipar o que antes exigia vários, os primeiros postos a rarear são os de programação de nível de entrada e de greyboxing. Os recursos gerados aqui são sobretudo provisórios; isto não diz que chegam a um jogo acabado. Um caso datado de um estúdio a lançar um jogo cujo código ou níveis foram na sua maioria gerados, ou a cortar pessoal de prototipagem por causa destas ferramentas, moveria isto para a automatização.

Documentos de design e especificações de teste

Depois de tomadas as decisões, transformá-las num documento estruturado é o tipo de escrita que os modelos de linguagem já fazem bem: redigem especificações a partir de notas, mantêm as secções coerentes, transformam um design em casos de teste e produzem fluxogramas a partir de uma descrição. Os estúdios podem adotá-lo a baixo custo dentro de ferramentas que já usam, e um documento errado é apanhado na revisão e não pelos jogadores. O que a ferramenta assume é a escrita, não as decisões que o documento regista, e alguém continua a ter de verificar se o documento corresponde ao que foi construído.

Isto retira horas, não uma função: poucas pessoas são contratadas só para escrever documentos de design, por isso o efeito aparece como designers a gastar menos tempo em papelada, ou como menos designers júnior cujo primeiro trabalho era manter os documentos atualizados. Voltaria atrás se os estúdios vissem os documentos gerados afastarem-se do que foi realmente construído com frequência suficiente para deixarem de os usar.

História, personagens e texto do jogo

Os modelos de linguagem escrevem texto fluente em qualquer registo, o que torna barato redigir a maior parte do texto de um jogo — descrições de objetos, falas incidentais, variantes da mesma observação. A história e as personagens são diferentes: transportam a identidade do jogo, os jogadores notam uma fala fraca e muitos jogadores reagem mal a texto que acreditam ter sido gerado. Os contratos dos argumentistas, e as regras sobre se o texto gerado por máquina pode ter dono, também travam o seu uso em jogos lançados, por isso o argumentista edita rascunhos em vez de entregar a voz.

Há uma divisão dentro desta tarefa: o texto em grande volume pode passar para a automatização enquanto a história principal fica com as pessoas, e este juízo cobre as duas. Não diz quantos postos de escrita restam. Um lançamento datado em que a maior parte do texto foi gerada em escala e os jogadores a aceitaram, ou uma mudança nas regras sobre a propriedade do texto gerado, moveria isto.

Revisões de design e liderança da equipa

Este trabalho é persuasão e arbitragem entre pessoas que querem coisas diferentes: artistas, programadores, produtores e a editora. As ferramentas resumem reuniões e acompanham tarefas, mas o valor está em decidir que funcionalidade é cortada, manter uma equipa numa única visão e ter a confiança para tomar essa decisão, e isso vem da posição de uma pessoa na equipa. Nada na tecnologia atual dá a um estúdio motivo para deixar uma máquina resolver essas discussões.

Liderado por pessoas diz que a função de coordenação sobrevive, não quantos coordenadores: se as equipas encolherem porque construir é mais rápido, são precisas menos pessoas para as liderar. Mudaria se os estúdios começassem a gerir a produção com ferramentas de planeamento automático que tomam as decisões de calendário e de corte e que os responsáveis apenas aprovam.

Definir as regras para o conteúdo gerado

Quando recursos e personagens gerados entram num pipeline, alguém tem de decidir o que é permitido: que arte é provisória e qual pode ser lançada, o que uma personagem que improvisa diálogos nunca pode dizer, e como manter um registo da origem de cada recurso para os detentores das plataformas e as editoras. É trabalho de design com arestas legais e reputacionais, e cabe aos designers e aos responsáveis técnicos porque conhecem os sistemas.

Uma tarefa nova não é um emprego novo: na maioria dos estúdios faz parte da semana de um designer ou responsável que já existe, e só cresce na medida em que o conteúdo gerado é de facto lançado. Cresceria até se tornar funções próprias se os detentores das plataformas ou as regras começassem a exigir que os jogos declarem o conteúdo gerado e mantenham registos de origem.