Criando Documento de Design

Para se programar um jogo é necessário um programador (e talvez um artista) com um dinheiro necessário para o investimento e uma data final. A documentação não precisa ser levada muito a sério agora. Você sabia o que queria fazer e o fez. Se existiram algumas mudanças ao longo do caminho o único que teria que saber a respeito era você. Atualmente, uma perfeita e legível documentação pode significar a diferença entre um rápido e satisfatório caminho ao inferno e uma suave cavalgada para a paz.

Como trabalha o sistema

A maioria dos jogos passam por três estágios durante o processo de desenvolvimento desde o design a produção. Pense neles como o “flash,” o “papel,” e o “trabalho duro”.

No primeiro estágio, o conceito do papel atua em dois sentidos – um como um papel onde você coloca suas idéias claramente para não se perder durante a confecção do seu jogo – e como uma ferramenta de vendas para quem obter o produto poder ser cadastro para seu controle. As vezes, este estágio envolve um trabalho de protótipo que te dá a chance de rever suas idéias e erros.

O estágio intermediário envolve muitas discussões com os artistas, animadores, musicistas e engenheiros que estão envolvidos na confecção do seu jogo para determinar as idéias.

No estágio final a administração do projeto, geralmente é deixada sob responsabilidade de algum expert em colisões. O designer original deve ser uma parte integral do time, mas em muitos casos – especialmente em grandes companhias – ele termina como um tipo de consultor.

Sem dúvida o documento de design é onde o pai do projeto exerce maior influência pois foi ele quem imaginou e organizou seu produto, o jogo. Se você, o designer, tiver decidido ser o gerenciador do projeto, não se iluda em pensar que você pode controlar tudo facilmente. Um projeto complexo envolve muitas pessoas talentosas. Programadores qualificados e artistas criativos tendem a ter idéias próprias. Enquanto você quer criar um cavalo por exemplo, o artista pode pensar em criar um unicórnio e o programador pensa em criar um camelo. Uma boa documentação assegura que você planejou tudo e este foi aprovado por todos os envolvidos na criação do jogo. Com isto todos lutam por uma mesma causa. Pense nisto como um grande grupo de jazz – eles são colocados todos em mesmo lugar seguindo uma melodia, porém eles podem improvisar sobre esta melodia.

Sua documentação é como um intermediário entre sua mente e seu mundo real. Ele assegura que o que você tem em mente é algo que você pode transformar em real.

Finalmente lembre-se do que qualquer bom jogador irá dizer: “Uma boa arte está em seus detalhes.” Quando você pensou em seu jogo você não pensou no tipo de chão que iria utilizar. A partir do momento que você começar a notar isto, as modificações ocorrerão normalmente.

Criando o documento

A parte do protótipo do projeto é definitivamente uma parte muito interessante – por mais difícil que possa parecer. Mas novamente, são os detalhes que chamam a atenção do jogador. Quanto mais detalhes sua mente pode imaginar, melhor designer você será.

Um desenvolvimento excitante resulta em um excitante jogo também. Algumas das melhores partes do muitos projetos foram descobertas quando estes estavam em sua fase final. Infelizmente a pressão do tempo e do custo investido não permite você ter uma interação tão real com todos os conceitos ditos até aqui. O desafio é criar um documento de design que irá permitir seu projeto aceitar algumas adaptações imediatas sem perder a integridade do projeto original.

Os três estágios da documentação

X Conteúdo Propósito
1. Conceito do Papel Gênero, público alvo, audiência, descrição, informação de marketing, custo e tempo de desenvolvimento. Ele define o conceito da meta a se atingir; vende as idéias ao clientes e demais interessados.
2. Design de Documento Descrição do corpo do projeto em todos os detalhes e o método pelo qual será implementado cada elemento. Ele assegura que o que é produzido é realmente o queremos produzir.
3. Produção da Documentação Tempo de administração, tarefas de banco de dados, técnicas específicas. Ele apresenta o documento de design no tempo e dentro do orçamento.

Dez pontos para a criação de um bom documento de design

A Alma do jogo

Se um jogo foi desenvolvido somente como uma entrada e saída de dados automática – algo como um código que está apto para informar como o trabalho está fluindo de acordo com os dados inseridos pelo usuário – você pode vir a ter um documento pobre e seco documento descritivo. É por isto que a documentação tem quer ser feito por pessoas criativas que conhecem o que dizem; assim temos uma documentação feita com muita criatividade e imaginação.

Ele trabalha assim: você fornece algumas abreviações para os artistas e discute com eles o que fazer. Faça o mesmo com os programadores e você vai ver os dois grupos normalmente pensam diferente. Depois de discutir com todos, veja as melhores idéias, exiba o resultado esperado à todos e comecem a trabalhar. Agora imagine a seguinte situação:

… e naquela noite em torno de 2 da manhã, somente a constelação do C++ levantou-se no oeste, o programador tem uma crise de meia-vida e come a pensar, “O quê? Eu continuar sendo um programador para o resto de minha vida? É isto que minha mãe espera de mim? Eu posso criar um jogo como qualquer um outro pode!” E suas mãos começam a digitar códigos.

Ao mesmo tempo o artista que acabou de ligar sua máquina tem uma queda de sono enquanto espera pela renderização de uma complexa imagem 3D. Sem saber se ele está sonhando ou não ele imersa em seu mundo selvagem de gênio, onde a fantasia e a realidade misturam-se em um só e, tudo o que foi projetado e discutido é totalmente modificado.

Na manhã seguinte seu cavalo transforma-se em um unicórnio com duas corcovas. Com pessoas criativas instruções não são o bastante. Você precisa de inspiração.

Em seu documento de design, não satisfaça apenas você com pequenos detalhes e descrições de cada artigo. Perca seu tempo em escrever o que você quer passar ao jogador que utilizar seu jogo, o propósito de cada elemento na tela, a experiência de cada usuário e qualquer outro aspecto da alma do jogo.

Por exemplo, imaginando que você está projetando um atirador. Você quer que seus jogadores tenham alguns desafios antes de chegar até o encontro do atirador. Para isto você coloca durante o caminho do jogador ao atirador alguns buracos, cercas, terrenos acidentados, etc. Para isto você precisa explicar para todo o time de desenvolvimento do jogo estes detalhes para eles poderem entender seu objetivo com isto. Com isto você terá resultados gratificantes ou até melhores do que o esperado.

Legível e entendível

Vá em frente, forneça à suas pessoas uma documentação com 10 páginas, sem marcações, 80 caracteres por linha e espere que as pessoas leiam isto. Você deve pensar na documentação como algo fácil, ou melhor, quando escrever a documentação pense na pessoa que vai ler como um leigo e verifique se o que você escreveu foi entendível para este leigo. Se sim você criou uma boa documentação.

Eu pessoalmente tento seguir alguns passos para conseguir um resultado satisfatório para meu layout.

  1. Bastante espaços em branco para tornar a leitura limpa e agradável
  2. Fontes agradáveis para a leitura
  3. Cabeçalhos destacados
  4. Espaços entre os parágrafos
  5. Pequenas linhas de texto
  6. Direcionar o olhar diretamente ao material que julga mais importante
  7. Use uma hierarquia, formato “2D”
  8. Quando tiver muitos problemas chame por uma tabela, planilha eletrônica ou gráfico. Utilize-os para uma melhor sensibilidade dos fatos.

Prioridade

Agora que você já notou que está lidando com egos conscientes, você deve estimar algumas prioridades para o jogo. Não há garantias mas se você utilizar estas prioridades em pequenas quantidades, elas ganharão muito respeito. Mas não pare aí. Conforme você tem idéia que necessitam de prioridade idealize técnicas para contornar esta situação.

Existem também algumas coisas que podemos considerar como lixo – isto ocorre quando você como designer pensa em alguma coisa mas infelizmente é algo inútil, acontece bastante nesta área. Por isso veja realmente o que você necessita com prioridade seguindo esta lista de prioridade:

  1. Indispensável
  2. Importante
  3. Se possível
  4. Rejeitado

Você também pode associar figuras ou cores para estes itens da lista para facilitar.

Detalhes

Um documento sem detalhes é inútil. As generalidades podem ser interpretadas por alguém da maneira que este alguém quiser. “Thou Shalt Not Kill” significa uma coisa para Moisés e uma outra coisa bem diferente para um conquistador espanhol. Detalhando o que você quer dizer você conseguirá passar corretamente seu pensamento. O mesmo acontece em seus documentos: Uma vez escritos alguns detalhes práticos e dados alguns exemplos, suas idéias tornam-se mais concretas.

Por exemplo, não diga, “Bronze bird is invincible.” Descreva exatamente o que acontece, quais são os pontos que comprovam esta afirmação. Com certeza um verdadeiro artista não vai querer seguir suas especificações mas com certeza ele irá entender o que você quis passar.

Nunca escreva por exemplo, “Neste ponto os usuários terão que apertar a tecla de pular mais a tecla de direção para cima para poder escalar a parede”. Escreva o acontecerá com ele se ele não fizer o que você disse. Explique sobre o ambiente e sugestione que é possível escalar a parede.

Não diga, “Bongo Man é mais forte que o Bongo Boy, mas o Boy é mais rápido em seus reflexos”. Utilize tabelas e gráficos que comprovam isto. Além disto você completar esta tabela com dados que comprovam por exemplo com dados em qual dos dois personagens o impacto é maior em uma queda.

Utilize sempre beta testers para melhorar e testar seu produto. Com eles você pode melhorar seu produto em 100%.

Demonstração

As vezes algumas poucas anotações são o bastante mas quando você quer demonstrar sua idéia você deve uma animação ou algo que chame a atenção. Quando o comportamento dos elementos tornam-se complexos e ambíguos para descrever em um papel, você deve criar um protótipo. O lado benéfico do protótipo é que esta é a melhor e mais elegante solução.

Quando você fornecer as animações e os protótipos você verá o resultado. As animações representam um gigabyte de palavras, mas as palavras podem comunicar algo que a animação não pode. Por isto a mistura de ambos de forma dosada resulta em um ótimo trabalho.

Funções

No mundo real o “como” determina o “o que”. Por exemplo, suponha que você está trabalhando em um jogo de moto de corrida. Você declara que suas motos devem ser balanceadas. Você fornece uma tabela que indica como elas são balanceadas. Então você declara que um beliscão será necessário. Então você planeja como beliscar. Qual é o processo? Suponha que o personagem principal seja o Fantasma da Opera. Descreve como o teclado do usuário está mapeado para funcionar como um órgão. Forneça uma função para cada tecla. Especifique quantos canais de som estão disponíveis. Então documente isto. Dois diferentes “como” pode resultar em diferentes trabalhos.

Alternativas

A administração do projeto toma muito tempo. Pessoalmente eu acho que isto ocorre em qualquer setor e não somente na programação de jogo. O mais radical na tecnologia de jogos é que apesar de ser algo que atualiza-se vertiginosamente em pouco espaço de tempo, você consegue estar sempre por dentro das novidades.

Vamos pegar como exemplo o teclado como um órgão. Seu projeto descreve o último método de obter dados do usuário para retornar algo que cause espanto e medo. Como tudo que nós discutimos até agora, sua documentação para obter um bom resultado é a única saída que existe.

Um dos meus maiores erros era perguntar aos meus engenheiros “É possível ser feito?”. Mais especificamente a resposta para esta pergunta encaixa-se em uma destas três categorias:

  1. (Programador Ruim) “Com certeza, sem problemas.”
  2. (Programador Simples) “Não. Isto não pode ser feito.”
  3. (Programador Primeira-Classe) “Eu não posso fazer assim e isto vai me levar duas semanas”; ou ainda: “Eu posso fazer uma leve modificação desta forma mas isto vai demorar umas cinco horas.”

Sempre peça por mais de uma opinião para ver quanto tempo algo vai levar para ser feito. Então indique sua preferência.

Vida ao jogo

Eu já te avisei sobre a inspiração e a espontaneidade para a criatividade que torna suas idéias reais. Você precisa permitir algumas modificações em seu documento.

Eu aprendi isto como a composição de uma música na University of British Columbia. Com muito trabalho eu escrevi uma obra musical Renascentista da qual me orgulho muito. Meu professor gostou muito também. Porém quando o maestro da faculdade pegou minha obra ele tomou sua caneta e começou a modificar alguma notas. Para mim aquilo foi horrível, alguém mexendo em minha criação. Mas depois de corrigido eu notei e aprendi que não acertamos tudo na primeira e por isso devemos sempre corrigir alguns defeitos que venham a existir em nossas criações.

O fato é não importa que você não acerte tudo na primeira (o que também é algo quase que impossível). O importante é não levar a público um trabalho mal feito, sem correções. Por isto é que as modificações são tão importantes.

Aqui está alguns tipos de mudanças que são toleradas pois não corrompem a idéia original e sabota o processo de desenvolvimento:

  1. Tenha certeza de ter gravado sobre os aspectos que são essenciais para o conceito do jogo e que não devem ser modificadas.
  2. Tenha certeza que todos entendam o sentido do jogo em cada detalhe que for proposto durante o jogo.
  3. Se a informação estiver repetida esta deve ser referenciada. Caso contrário, se existirem mudanças você pode terminar com instruções contraditórias.

E aqui está alguns tipos de implementações de acordo com o estágio do desenvolvimento:

  1. Quando uma mudança é sugestionada, cheque em seu documento de design e veja se esta estará de acordo com a “alma” do seu jogo.
  2. Cheque se a mudança é uma mudança isolada ou se ela irá causar um impacto muito grande em todo o seu jogo.
  3. Atualize o documento de design e inclua as razões da mudança. Se você não fizer mudança alguma, explique o porquê dela ser rejeitada.
  4. Modificações, deletações e rejeições devem ser salvas em um documento central para uma coisa não ser discutida duas vezes.
  5. Todos devem estar trabalhando para a mesma versão. Versões antigas devem ser destruídas.
  6. Crucial, Vital e Urgente: O documento de design deve ser mantido sobre o controle de uma única pessoa.

Documente cada detalhe

Eu já peguei algumas documentações que nem o número da página sequer tinha. Eles achavam que as pessoas que adquiriam o produto não iriam utilizar o manual. Um bom manual deve ter além das páginas numeradas, deve ter também a data impressa em cada página. Além disto um cabeçalho que indique o que você está lendo a respeito. Utilize as palavras destacadas quando tratarem de materiais importantes. Crie uma completa Tabela de Conteúdo.

Você deve utilizar uma documentação utilizando o HTML e fornecendo links para os detalhes do manual. Lembre-se que as pessoas preferem muito mais a versão impressa do manual para consultas e não somente a documentação HTML.

Distribuição

Depois de tudo isto você precisa fazer com o manual seja fácil de ser lido e compreensível ao seu público alvo. Um monte papel não é algo atrativo para a leitura. Coloque somente as coisa mais importantes e que podem ocorrer mais freqüentemente.

Crie uma lista de quem deve ter uma cópia do manual original. Guarde sempre esta lista. Imprima tudo o que for a respeito da documentação do seu produto com data e guarde com você para utilizações futuras que, acredite ou não, você vai precisar. Quando houverem atualizações forneça todos os detalhes desta atualização. Em alguns pontos, novos livros devem ser editados e os antigos serem jogados fora.

Conclusão

Os criadores de filmes utilizam scripts de filmes. Os arquitetos utilizam projetos. Músicos utilizam partituras. Você como um programador de jogos além de sua idéia vai precisar de uma boa documentação. Com isto seus projetos serão reconhecidos e além do mais a gratificação pessoal de conseguir alcançar seu objetivo é o que mais importa.



  1. Muito bom… esse texto esta de arrepiar, e creio que ira ajudar muita, muita gente mesmo.

  2. Legal!! gostei do texto… é aplicável em outras áreas do desenvolvimento de software tambem!!

    Já tinha lido esse texto em: http://desenvolvimentodejogos.wikidot.com/criandodesign

    Foi de la que voce pegou?!?!? Voce sabe dizer quem é o autor original?!?!?!

  3. Ola KrinosX,

    Que bom que gostou ^^

    Eu escrevi e eu postei la no http://desenvolvimentodejogos.wikidot.com

    Clique la no history que tem la em baixo na pagina http://desenvolvimentodejogos.wikidot.com/criandodesign.

    Vlw. =D

  4. Ola!

    Depois de muito tempo.. heheh Agora eu vi la que o texto é criação sua! Muito bom mesmo!!!

    (aquele wikidot é meio estranho.. nunnnnca eu ia advinhar que tem que clicar no history!! parabens!!)

    E o seus projetos? voces tinham um projeto do Tales of Labirinthia não é? par aonde foi?

  5. […] Criando Documento de Design […]

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s



%d blogueiros gostam disto: