apresentação modificada do meu trabalho de conclusão de curso

Carina M. B. da Costa - Missae no Sekai

UNIVERSIDADE DE SÃO PAULOFaculdade de Arquitetura e Urbanismo da Universidade de São Paulo Curso de Design

Trabalho de Conclusão de Curso Práticas de Documentação para Projeto de Games

Orientador: Professor Drº Ricardo NakamuraOrientanda: Carina M.B. da Costa

São Paulo, 07 de dezembro de 2012:


TCC1: Evolução, Metodologias e GDDConsiderações iniciais e crescimento da complexidade:

game = jogos plataformas eletrônicas

complexidade de produção cresce com o passar dos anos.

necessidade de divisão de tarefas.

conhecimentos variados.

01

Jonathan BLOW. Imagens retiradas de retirados de:: <http://dl.acm.org/citation.cfm?doid=971564.971590>Acomplexidade implícita na aplicação de tecnologia (do 2d para o 3d) e de meio interativos (single player, multi-player, massive multiplayer).


Engenharia de Software

Organização da indústria

Organização acadêmica

Organização observada na pesquisa

Game é um software Organização Documentação

Comunicação Multidisciplinaridade

Tradução de imaginário

Criação do novo intuitivo

Design

GDD

Arte

Recorte:

02


Game Design Document:

03

Game Design Document

Ferramenta de comunicação e articulação

Natureza Evolutiva

Game designer é responsável

Foi estudado dentro do contexto de grandes produções.

“Without design documentation to direct their efforts, the individuals on a team might interpret what they know about the game in their own unique ways, working hard, but not necessarily toward the same ends.” [FULLERTON, 2009, 394]

Positivos: auxilia na comunicação captura a essencia do game

todos participam

Negativos: tende a ser extenso

tende a cair em desuso

manuseio e redação complexos manutenção complexa

“Always keep in mind that you are not writing the design document for the sake of writing it—your objective is communication, so do whatever it takes to accomplish that goal” [FULLERTON, 2009, 395]


TCC2: Pesquisa Qualitativa e Proposta

04

O cenário brasileiro de desenvolvimento de games:

Novo Recorte:

cenário diferente do apresentado por Fullerton

produção de proporções menores

produção menos experiênte

Devido ao cenário diferente do descrito por Fullerton, acredita-se que as necessidades de documentação também o sejam. Foco em empresas e grupos pequenos pois representam a maioria dos desenvolvedores existentes no Brasil.

Pesquisa qualitativa para obter mais detalhes com menos amostras.

Tratamento de dados beseado em algumas recomendações da metodologia de tratamento de dados qualitativos Grounded Theory.

Questionário qualitativo: traçar um panorama de trabalho

identificar dificuldades de documentação

Sobre a coleta de dados:

Carina M. B. da Costa - Missae no Sekai 05

Resultado da pesquisa:

participaram da pesquisa 33 pessoas, com idade média de 26 anos; dos 33 participantes, 5 eram do sexo feminino e 28 do sexo masculino.

- Quantos participantes, idade e sexo:

média de 3 anos de experiênica; atuação variada, desde empresas com 30 funcionários, até duplas independentes de desenvolvimento. Imagem SPJam 2012 retirada de < http://media.tumblr.com/tumblr_lvgh9kPPB71qd5vs7.jpg>

- Experiência e atuação na área:



em torno de 5 a 6 pessoas;

- Trabalham em um mesmo projeto:

comercial; por paixão ou hobbie;

portfolio/expressão artística;

criar algo original;

- Motivação para fazer games:

comerical

paixão/hobbie

expressão artística

portfolio

criação original

aprender

entreter

realização pessoal/ reconhecimento

colaborar com a comunidade de desenvolvedores

pesquisa



A maioria dos participantes afirma trabalhar de maneira mista: tanto em um mesmo local física, quanto em espaços distribuídos.

Esta pergunta é importante para saber como se comunicam durante o processo de desenvolvimento.

- Trabalham em um mesmo local:

Dependendo do momento do projeto, é melhor trabalhar junto.

ambos mesmo local de forma distribuída



- Tipos de ferramenta para comunicação e armazenamento de dados:

google drive; drop box;

skype;

e-mail;

GIT;

SVN;

Há uma certa confusão entre documentação e backup.



- Tipos de game e dimensões:

mobile, web e pc; 58,1% dos entrevistados afirmaram fazer games de pequeno porte; 32,2% afirmaram fazer games de médio porte; 9,7% afirmaram fazer games de grande porte;

conceito de dimensão variado;

A complexidade de se fazer o game como medida de dimensão nem sempre precisa estar relacionada ao tempo de produção.

Ex: um problema difícil, não necessariamente leva muito tempo para ser resolvido

quão complexo foi fazer o game.

quantidade de funcionalidades.

quanto tempo de gameplay.

quanto tempo de produção.



- Documentação:

80,7% afirma documentar o projeto, ou pelo menos, tentar;

A maioria utiliza alguma ferramenta de texto (em geral o google drive) para criar a documentação.

Muitos separam a documentação em: documento de arte documento de design documento de programação

Mais da metade utiliza o termo Game Design Document;

Documentar o projeto e ter um backup do mesmo foi frequentemente confundido;

começa-se a documentar, mas dificilmente se mantém o ritmo.

sim não as vezes



- responsável:

responsabilidade é de todos;

há a necessidade de mesmo assim, ter um ou dois responsáveis por escrever;

apenas 19,3% atribuiu a responsabilidade somente para o game designer;

32,2% acham que a responsabilidade é de todo mundo.

- o que é documentado:

jogabilidade/mecânica;

game design;

programação;

high concept;

referências;

tarefas pendentes;

Observou-se pelas respostas, uma variedade de entendimentos do que engloba ser game design.



- problemas de documentação:

71,4% tem problemas em documentar o projeto;

negligência;

desorganização;

preguiça;

falta de atualização - falta de leitores;

não saber como documentar;

falta de interesse da equipe;

a documentação é tida como importante, mas ainda é considerada uma atividade

muito burocrática.

dedica-se muito tempo, e não se reaproveita o material gerado.

Vira um ciclo! Não se atualiza porque ninguém lê, ninguém lê porque não se atualiza...

Muitos tentam deixar a documentação mais visual e menos escrita.



- reaproveitamento da documentação:

quase 50% não reutiliza ou nem ao menos, chega a finalizá-la;

referências para projetos futuros;

documentação de erros;

reaproveitamento do modelo;

treinamento de novos funcionários.

Documentar para aprender!

- outras respostas interessantes:

portfolio.

apresentar para clientes.

apresentar para investidores.

divulgação em blog.

O ato de documentar foi bastante associado à demonstração de profissionalismo.



- considera-se indie?

66,7% consideram-se desenvolvedores independentes; estar associado a um cliente ou publicador

= limitador criativo.

- o que significa ser indie?

- outros comentários menos citados a respeito do que é entendido por indie:

controle criativo total! Fazer o que quiser sem interferência de um investidor;

trabalho autoral;

criar sem auxílio financeiro;

não estar vinculado à um publicador;

ser original em suas criações;

não precisar seguir tendências;

produção horizontal. O game é de todos!

indies criam somente por hobbie e não tem intenção de comercializar.

alguns se consideram indies por não verem seus trabalhos como profissionais ainda...


Requisitos de proposta de documentação:

- requisitos obrigatórios:

Permitir reaproveitamento de seu conteúdo;

Documentar de forma mais sucinta;

A documentação precisa ser de fácil manuseio;

A documentação precicsa ser de fácil consulta;

Permitir o gerenciamento do projeto;

Ser de fácil manutenção;

Documentar de forma mais visual;

15

- requisitos desejáveis:

Ajudar a entender a necessidade de documentar o projeto;

Suportar diferentes tipos de mídia;

Identificar quem modificou o que;

Ter espaço para monitorar o que aconteceu com o jogo após o lançamento;

Funcionar de forma colaborativa;


Proposta escolhida:

- partidos:

Desenvolvimento de um aplicativo ou ferramenta que auxiliasse na tarefa de documentar o projeto;

Organizar em etapas, a produção de games, focando em técnicas, exemplos ou práticas de documentação;

Ferramentas podem ser adotadas, ou não adotadas por completo.

Práticas podem ser utilizadas em partes e ajudam a criar um hábito.

De nada adianta o uso de uma ferramenta se a própria noção de organização não for cultivada.

Uma ferramenta é um auxílio para um meio, no entanto, entender o “meio” do qual estamos falando é prioridade com relação à ferramenta.

16

- opção escolhida:

Organizar em etapas, a produção de games, focando em técnicas, exemplos ou práticas de documentação;


Organização das etapas e documentação:

- etapa de conceitualização:high concept;

mecânica base;

17

Documento principal e documentos periféricos.

“De acordo com Flynt [2005], um dos grandes problemas que ocorre no processo de desenvolvimento de jogos digitais é iniciar sua produção sem a existência de um escopo claro e definido.” [SORIA e FANTINI, 2012, 58]

- o que é difícil?

fechar as funções básicas (fechar um escopo);

parar com a busca de referências;

- como pode ser documentado?

ainda é algo muito mutável: docs, wiki;

(cuidado com o tamanho do documento);

início de uma lista de “To Do” já pode ser feita;

O material pode ser separado por pastas: pasta pessoal e pasta do game;

O importante é divulgar somente o material selecionado, para evitar discussões sem sentido e perda de tempo.

Separar os materiais por algum assunto para facilitar futuras buscas.



- exemplo: The Tunnel

a. Especificações Iniciais:

Nome do jogo: The Tunnel (provisório)

Plataforma em que será publicado: portais de jogos em flash

Resolução do jogo: 640x480 (tamanho OK pra jogo de flash para portal)

Engine: flashpunk

Input: Mouse apenas. Função clique e função “drag and drop”

Resolução dos tiles: 32x32 pixels (confortável para clicar)

precisa de avatar? (a ser testado)

b. Objetivo - High Concept:

Você é um construtor de rodovias e deve cavar túneis para que as ruas possam ser construídas. Seu chefe é um mão-de-vaca e forneceu equipamento aleatório. Agora você terá de se virar com o que vier! Mistura de card game e puzzle com fases rápidas. Conecte a entrada e a saída através dos túneis, mas tome cuidado para eles não ruírem. Use com sabedoria as peças que se mostram disponíveis para você.

18


c. Ações base (iniciais):

- quebrar pedras;- encontrar coisas;- construir coisas (drag and drop?);- sair da fase;- usar poderes (aumentar visão, quebrar pedra, embaralhar peças);- desistir da fase (recomeça);- pausar o jogo (abre menu);

Mecânica básica:

1. clicar nos “tijolos” para cavar.

2. caso cave muitos buracos, o túnel pode desabar (quantidade de tijolos que podem ser cavados precisa ser testada para definir um número ideal)

3.cada peça de túnel só tem uma entrada e uma saída.

4. Alguns tijolos são mais duros do que outros, precisando de algo especial para serem removidos.

5. o jogador contará com os seguintes poderes (provisório): aumentar poderes, dinamite, embaralhar peças.

6. o jogador poderá ver 3 peças de túnel por vez


19


- etapa de prototipação:

testes simples;

encontrar show stoppers;

Por Exemplo:

Se um game tiver um mapa que vai aparecendo por partes conforme o personagem anda (como no game Bastion ) não é necessário ter o mapa final para fazer este teste. Crie algo genérico, só para testar o movimento de aparição.

- o que é difícil?:

não se apegue ao protótipo;

faça protótipos do necessário;


Game: Bastion. Imagem retirada de < http://img64.imageshack.us/img64/9476/bastion2011081615074377.png>



- repassando conceitos:

comparar o antes com as informações de agora;

anotar o que mudou e por que mudou;

começa-se a ter noção do tamanho do projeto;

cronograma;


tabela;

fluxo de telas;

como era

funções básicas:

- pular;- andar;- correr;- atirar;

engine:

- flashpunk;

como ficou por que mudou?

funções básicas:


engine:

- constructor;

engine:

- flashpunk não permite uso do botão direito para comparar decisões.

Carina M. B. da Costa - Missae no Sekai 22para estimar a quantidade de trabalho.


Organização proposta das etapas e documentação:

documento periférico



documento principal




23



o que tem?o que é difícil?como anotar?exemplo



etapa de conceitualização

etapa de prototipação

etapa de desenvolvimento

lançamentoversão beta e

testesversão alfa e

teste

o que tem?o que é difícil?como anotar?correçõesexemplo

resultado finalreaproveitamento

Repassando conceitos Repassando conceitos

o que tem?o que é difícil?como anotar?correçõesexemplo

24



pontos altos das práticas propostas:

- selecionar melhor as informações a serem divididas em grupo;

- uso de tabelas;

- uso de diagramas para entender os pontos importantes do projeto;

- comparar sempre o estado atual do game com o que se tinha definido anteriormente;

- principalmente, anotar por que as coisas mudaram;

- não tenha preguiça de fazer o simples antes de evoluir para o complexo.

25


como era

funções básicas:


engine:

- flashpunk;

como ficou por que mudou?

funções básicas:


engine:

- constructor;

engine:

- flashpunk não permite uso do botão direito


26



27



28



- etapa de desenvolvimento:

pensar mais no funcionamento do game e menos aonde será desenvolvido;

possibilidade de testar se o game está divertido;

explorar partidos de decisões do game;

cronograma (aqui não dá pra escapar);


organizar a documentação, especialmente entre:ideias testadas e ideias a serem testadas.

anotar por que certas opções foram aceitas e por que certas outras não.


- repassando conceitos.novamente comparar o antes e o depois;


anote em um documento periférico as variações de funcionalidades que se quer explorar no game;

anote também, as que foram testadas: Se foram aprovadas, escreva o por que. Se não foram, escreva também;

anote no documento principal somente as funcionalidades que já foram testadas e aprovadas;

atualizar as tabelas;

procure não anotar informações muito incertas, de uma mesta etapa de projeto, no documento


principal, isso ajuda a manter a organização e facilidade de manuseio do mesmo.

criar uma bisão geral do projeto com uma linha do tempo ou lousa;

atentar-se para o detalhe da escalabilidade desta visualiação, portanto, anotar somente as informações já fechadas do projeto;

procurar mensurar o tempo gasto em cada etapa ou quanto do projeto já foi terminado;


Mecânica (inicial)O jogador pode, em sua vez:

Clicar sobre um tile de terra para cavar. - Condições:

-O tile de terra DEVE estar adjascente a um tile vazio para ser clicável;

-Uma vez com o túvel construído, não é possível cavar por suas paredes, apenas em sua entrada e saída;

-Não é possível cavar na diagonal;

-Não é possível cavar as pedras, a não ser que tenha o item certo.

- exemplo: mecânica inicial


Verde: você poderia cavar aqui; Vermelho: você não poderia cavar aqui


- exemplo: lousa (Realtime board)




- versão alfa e testes.modificações de acordo com feedback de testers;

registrar da melhor maneira possível o feedback;

- repassando conceitos.como era, como ficou e por que mudou;

- correções.

realizar modificações de acordo com os dados dos testes até que o game esteja bom o suficiente;

Se os testers já não se perdem tanto, ou estão jogando o game como era planejado, então talvez isto seja “bom o suficiente”;

Ou se o game já tem as funcionalidades mínimas para funcionar dentro do esperado para seu lançamento.



documento periférico para cada tester;

no documento principal, anotar somente as conclusões finais dos testes, as informações que geraram mudanças no projeto;

documento periférico para bugs;

no documento principal, anotar somente os bugs que foram mais trabalhosos, ou que geraram aprendizagem;

utilizar técnicas de teste de usabilidade pode ser uma boa ideia (narrar em voz alta oq ue estão fazendo, gravar vídeos dos teste etc);

Teste de versão alpha para o game The Tunnel - protótipo simples parte no computador, parte de papel)



- versão beta e testes.hora de fechar o projeto;

últimos testes e ajustes finos;


respeitar o cronograma;

considerar que o game está terminado;

aqui, a documentação serve mais apra padrão de comparações entre resultado final e expectativas;


- versão final e lançamento.

Ao final de tudo, espera-se que uma pequena biblioteca tenha sido criada;

o documento principal é uma espécie de histórico dos pontos altos do projeto;

os documentos periféricos, são as detalhes do projeto.

Facilitam a inserção de um novo membro durante o desenvolvimento.

Informações específicas são mais facilmente localizadas uma vez que são independentes e não estão presas dentro de um documento grande.

podem ser reaproveitadas para portfolio, consulta, mapeamento de comportamento de testes, estudos de rendimento da empresa/grupo, redação de post-mortens, artigos etc...


- conclusão e observações.procurou-se estudar as necessidades de documentação e propor práticas que auxiliassem nesta tarefa, tanto no como quando no o que de se documentar;

precisa de ajustes;

Conclusão e questões:

pode ser refinado com tempo e experiência;

intenção do trabalho foi de colaborar com a troca de informações;

mostrar como documentar é importante para um projeto, seja pela organização, pelo aprendizado ou para não esquecer as informações úteis que o tempo apaga da nossa memória;

crítica ao mesmo erro cometido nas matérias de projeto do curso de design;

- questões tangenciadas:Video games como linguagem: características próprias? O que falta ser explorado?

Diferentes focos de core-mechanics inflingem em modificações de sequência de projeto?

Existe um ponto de partida ótimo para a criação de um game?

Como dimensionar o tramanho de um projeto de game?

Até onde backup e documentação são semelhantes a ponto de serem confundidos? O quanto um backup de projeto consegue transmitir informações do desenvolvimento em sí?

Existe um preconceito no Brasil com relação à produção nacional de games?

O quanto a visão dos próprios desenvolvedores de games brasileiros, a respeito deles mesmos diz o quão seriamente é encarada esta atividade?

36


obrigada! :)

apresentação modificada do meu trabalho de conclusão de curso

Documents