Como cliente, tentando fazer com que um codificador / programador desenvolva minhas idéias em um programa funcional, o que devo fornecer ao (s) meu (s) desenvolvedor (es)?


45

Eu sou o diretor de um grupo iniciante de desenvolvimento de jogos (digo "grupo" porque ainda não é uma empresa oficial). Recentemente, ganhei a disposição de alguns programadores que estão dispostos a me ajudar com o projeto, mas estão solicitando documentação.

Entendo a necessidade de documentação e tenho muitas de nossas idéias em alguns documentos diferentes, mas imagino que vou querer organizá-la de alguma maneira que os desenvolvedores possam entender de maneira individual e coletiva.

Há algo que eu deva deixar de fora desse documento; se sim, que tipo de coisas? Existe um modelo apropriado para esse tipo de documento; se sim, onde posso encontrá-lo? Há algo mais que eu deva saber oferecer aos codificadores antes que eles comecem a trabalhar?

Eu sei que tenho muitas perguntas sendo feitas aqui. Espero que isso não seja um problema. Agradecemos antecipadamente por qualquer orientação!


5
Liz England fez um bom trabalho na GDC 2016 sobre documentação acionável, adaptando a documentação do design de jogos para diferentes públicos , com referências a outras fontes úteis.
DMGregory

Como programador (quem está, de fato, fazendo um jogo), posso dizer que gostaria de um caderno inteiro de estatísticas detalhadas. Mas seria igualmente fácil para mim usar uma frase explicando o objetivo, a demografia a ser segmentada e a plataforma para criar exatamente o mesmo videogame.
Redwolf Programs

Respostas:


47

O desenvolvimento de jogos geralmente funciona um pouco diferente do desenvolvimento de aplicativos. A razão é que os jogos geralmente têm requisitos muito menos e muito menos rigorosos. Você não tem um problema comercial bem definido que seu software deve resolver. Os únicos requisitos verdadeiros de um jogo são "rodar corretamente na plataforma de destino", "apelar para o público-alvo" e "é divertido de jogar" (e talvez "venda muitas microtransações" se você estiver nessa seção da indústria ) Todo o resto está sujeito a alterações durante o desenvolvimento.

No entanto, para garantir que todos os desenvolvedores do jogo estejam trabalhando na mesma direção e não acabem lutando até a morte por diferenças criativas, você deve ter alguma "visão" codificada de como deseja que o jogo final pareça e jogue . Essa visão geralmente é codificada em um documento de design de jogos . Esse documento geralmente descreve:

  • A premissa básica do jogo:
    • O passo do elevador : a idéia principal do jogo, descrita o mais brevemente possível.
    • Qual é o gênero do jogo?
    • Quem é o seu público-alvo alvo?
    • Quais plataformas você está segmentando?
  • A mecânica do jogo:
    • Quais ações o jogador pode executar neste jogo e como elas afetam o jogo?
    • Quais entidades não-jogadores estão no jogo, como elas se comportam e como elas interagem entre si e com o jogador?
  • O escopo:
    • Quanto conteúdo você deseja que o jogo tenha?
    • Qual nível de qualidade você deseja que esse conteúdo tenha?
  • A direção estética do jogo:
    • Que ambiente geral você quer que o jogo tenha?
    • Como você quer que o jogo pareça?
    • Como você quer que o jogo pareça?
  • Quando se trata de história, isso depende muito do gênero. Alguns jogos não precisam de história. Muitos jogos precisam apenas de algumas frases. Mas se você estiver criando um jogo baseado em enredo, como um RPG ou aventura, isso pode ser de fato a parte mais longa do documento de design e pode incluir:
    • Uma descrição do mundo em que o jogo ocorre e seus principais locais
    • Uma descrição dos personagens importantes, sua aparência, personalidade e história de fundo
    • Um esboço básico do enredo que é contado durante o jogo

Se você procurar na web, poderá encontrar muitos modelos para documentos de design de jogos. A indústria de jogos é muito menos formalizada e com processos padronizados do que o restante da indústria, portanto você não encontrará o único padrão ISO para governar todos eles. Apenas tente encontrar um estilo que se adapte ao seu projeto, sua equipe e sua metodologia de trabalho.

No entanto, esteja aberto a mudanças durante o desenvolvimento. Quando documentos de design de jogos populares vazam para o público, intencional ou involuntariamente, você geralmente percebe algo interessante. Se você comparar essas notas iniciais de design com o jogo final, geralmente haverá muitas diferenças consideráveis. Isso geralmente é o resultado de um processo de design que os desenvolvedores de jogos chamam Fail Faster :

  1. Crie um design grosseiro
  2. Crie um protótipo simples
  3. Teste-o com uma mentalidade crítica e descubra o que não funciona nele
  4. Revise seu design
  5. Voltar ao estágio 2

Portanto, não tenha medo de alterar ou cortar recursos quando perceber durante o teste que eles não são tão divertidos quanto na sua cabeça. Além disso, esteja aberto a sugestões da equipe. A maioria das pessoas na indústria de desenvolvimento de jogos decidiu ingressar na indústria porque quer colocar em prática suas próprias idéias de jogos. Portanto, dar à sua equipe alguma influência criativa pode ser um grande motivador para eles. Mas como um bom produtor, também é seu dever dizer "Não!" se você acha que uma ideia não funcionaria ou excederia o orçamento.

Estou ansioso para jogar o seu jogo.


Muito obrigado! Seus detalhes respondem muito bem à minha pergunta e eu realmente aprecio a orientação. Farei o possível para colocar isso em prática em meus projetos. Para sua informação (também para qualquer outra pessoa), meu "grupo" pode ser encontrado em ataxiagames.com . Mais uma vez obrigado!
Graham Lewis

Eu também sugeriria dar uma olhada neste forum.unity.com/threads/game-design-document-template.240038 Como eu o usei com um amigo, isso nos ajudou muito a aprimorar a idéia e obter uma boa definição do que deve ser realizado de que maneira.
Nico

Não acredito que ninguém nunca fez essa pergunta antes, e essa é uma resposta incrível também! Tenho certeza de que isso ajudará muitas pessoas.
Brian H.

3
Um padrão ISO para governar todos eles / Um padrão ISO para encontrá-los / Um padrão ISO para trazê-los todos / E na documentação vinculá-los / Na terra do desenvolvimento em cascata, onde estão as especificações.
OnoSendai 29/10
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.