Que tipo de documento para design de jogos? [fechadas]

9

Que tipo de suporte / formato você usa para armazenar e difundir sua documentação de design de jogos? Wiki? Arquivos doc? Arquivos no Repositório? Pasta compartilhada? Google Doc?

Forneça prós e contras para cada um.

Klaim
fonte

Respostas:

14

Estou usando o Google Docs porque tudo o que realmente preciso é de um editor de texto on-line. Posso colaborar com pessoas on-line com relativa facilidade e sei que minhas informações estão seguras lá no caso de meu computador travar.

Outra opção que vale a pena procurar é usar o Dropbox . Coloque um documento do Word e você instantaneamente terá um ambiente colaborativo com controle de versão.

Sergio
fonte
5
PS O Google Docs é completamente INCRÍVEL para edição colaborativa em tempo real a partir da recente atualização (acho que em meados de setembro). O Dropbox, por outro lado, não possui resolução de conflitos (renomeia um arquivo conflitante, o que pode criar ainda mais confusão), por isso é terrível para a edição simultânea de arquivos, mas excelente para backup e compartilhamento / edição não simultânea.
Ricket 12/10/10
Existe uma maneira de ter o Google Docs local da empresa (como o servidor da empresa instalado)?
Klaim
11
@Klaim, se você obtiver o Google Apps no seu domínio, poderá. google.com/apps/intl/en/business/index.html
Jesse Dorsey
4
Noctrine, ainda é hospedado pelo Google. Ele apenas aparece no seu domínio, cortesia de uma entrada CNAME. Se você precisar que os dados estejam fisicamente na sua rede local, isso não funcionará. OTOH, a menos que você precise de uma autorização de segurança para trabalhar em seu "jogo", o último requisito é geralmente mais uma indicação de paranóia e megalomania do que qualquer outra coisa.
drxzcl
11
Sim, eu já conheço domínios (já tenho vários aplicativos do Google para meus domínios), mas digamos que você não tenha acesso à Internet, mas apenas a uma rede local?
`` Klaim
5

Wiki

Prós:

  • Versão mais recente sempre acessível pela web, de fora do local etc.
  • Bastante fácil de usar (se você se afastar daqueles com um naufrágio para formatar como o MediaWiki, isso é)
  • Indexação automática, pesquisa, categorização fácil
  • Fácil de atribuir alterações às pessoas e de responsabilizá-las pelas alterações
  • Suporta vinculação e torna mais fácil e eficaz fatorar detalhes
  • Pode vincular-se a páginas wiki diretamente de relatórios de erros internos e outras correspondências, facilitando muito a verificação de um bug
  • Histórico de versão e controle de revisão, geralmente embutidos

Contras:

  • Às vezes, MUITO fácil de mudar (* veja abaixo) e requer disciplina
  • As páginas podem ficar fora de sincronia quando editadas isoladamente (geralmente sem 'pesquisa e substituição global', por exemplo)
  • As páginas ficam órfãs ou substituídas e deixadas como campos minados em potencial para codificadores posteriormente. ( "Como assim, não estamos mais implementando isso? Ainda está no wiki de design!" )
  • A sintaxe pode ser um pouco esotérica, a menos que você obtenha o pacote certo
  • Precisa organizar a hospedagem ou aceitar o que está disponível on-line gratuitamente
  • Nenhuma rota clara no documento - como você lê tudo?
  • Difícil de imprimir. Você pode imprimir tudo com um clique? Você pode imprimir facilmente tudo o que é relevante para um determinado recurso para levá-lo a uma reunião? Você pode anotar a versão digital facilmente sem obscurecer o documento subjacente?

(* Usamos um wiki para um projeto e os designers sempre tentavam entrar e 'melhorar' partes dele, mesmo em recursos que haviam sido assinados e enviados para serem codificados. Em seguida, quando o controle de qualidade testava o recurso, seria um pesadelo, porque muitas vezes o design sugeriria algo diferente do que foi realmente codificado e seria necessário um trabalho frustrante para descobrir o que aconteceu primeiro, a alteração no design ou no código.)

Kylotan
fonte
11
Todos os seus Contras são realmente um problema se você estiver usando o Confluence, com exceção da hospedagem que não é gratuita, a menos que você o hospede no servidor da LAN e permita que outras pessoas participem via DynDNS ou serviço similar.
LearnCocos2D
O engraçado é que usamos o JIRA para o nosso projeto. Acho que ou ninguém considerava o Confluence também ou talvez o custo fosse muito alto. Eu votei sua resposta de qualquer maneira.
Kylotan
Documentos de design baseados em Wiki ... Por favor, por favor ... Não.
precisa saber é o seguinte
3

Arquivos de texto

No meu projeto atual, estou usando arquivos simples de texto sem formatação na pasta "Docs" do projeto, armazenada no repositório ao lado do código.

Prós:

  • A documentação é mantida próxima ao trabalho real, por isso é fácil de encontrar.
  • Formatação simples significa que é fácil e rápido manter a documentação.
  • Formato simples também significa que há pouco risco de perder documentação devido a falhas no servidor, corrupção de arquivos, etc.
  • O tempo de configuração absolutamente mínimo torna este um ótimo começo para equipes de desenvolvedor único ou pequenas (2-3 pessoas).
  • Usar o controle de versão significa que as alterações são rastreadas e, geralmente, é possível vincular as alterações na documentação diretamente com uma alteração no código.
  • Tão fácil de trabalhar como o texto, também é possível pesquisar, editar e assim por diante com as ferramentas de linha de comando.

Contras:

  • Mais de dois usuários e o documento sairiam de sincronia facilmente.
  • Como não há links, use um documento grotescamente grande ou vários documentos menores, mas desconectados.
  • Opções limitadas de formatação e publicação (embora seja fácil fazer conversões, como através do Markdown).
  • Tão fácil de trabalhar como o texto, geralmente a única maneira de obter pesquisa, edição avançada e assim por diante é usar ferramentas de linha de comando.

Não é algo que você deseja confiar para qualquer tipo de trabalho em equipe, mas o poder dos arquivos de texto no repositório para permitir que você comece a trabalhar não deve ser subestimado para o desenvolvedor único. Atualmente, uso um documento como um tipo de visão geral / planejador-mestre que contém o design geral, um segundo documento que funciona como uma lista de tarefas com itens específicos de que o jogo precisa, um terceiro documento como um rastreador de erros solto e documentos auxiliares para elaborado no "recurso x", conforme necessário.

CodexArcanum
fonte
2

Não use um editor / formato de documento que não seja compatível com vários usuários (por exemplo, MS Word, Open Office Writer). Somente uma pessoa pode editar o documento e, mesmo com o controle de origem, é muito fácil começar a trabalhar em uma versão desatualizada e, economizando, você basicamente destrói tudo o que os outros usuários fizeram desde a última vez que o usuário atualizou sua versão do documento.

As pastas compartilhadas são, de longe, a pior solução e não há risco absoluto para qualquer tipo de ativo que deva ser trabalhado em colaboração. Você nunca pode ter certeza de que alguém está trabalhando nesse arquivo no momento ou o fará nos próximos dois minutos. Você também não tem controle de alterações e não pode voltar para uma versão anterior em caso de desastre (erro humano ou estupidez humana ou negligência humana).

De preferência, use um Wiki, mas que seja amigável e seja verdadeiramente WYSIWYG. Pessoalmente, juro pelo Confluence , que também é usado em estúdios maiores para desenvolvedores de jogos e custa apenas US $ 10 para até 10 usuários e espectadores ilimitados.

A maioria dos outros wikis (MediaWiki, TikiWiki, etc.) tem a desvantagem de ter uma curva de aprendizado acentuada ou mesmo praticamente inutilizável por pessoal não técnico. Não que eles não pudessem aprender, mas eles (por direito) não aceitam usar um sistema de documentos que basicamente exige que você escreva códigos como HTML. Esta é minha irritação: Wikis que dizem que são WYSIWYG, mas tudo o que fazem é inserir a sintaxe no texto que você está escrevendo. Isso não é WYSIWYG!

A orientação para o uso de um wiki é colocar todos os cabeçalhos em uma página separada, para que você possa cortar o documento em várias partes gerenciáveis. O Confluence oferece recursos com os quais você pode agregar todas essas subpáginas em um único site ou documento, que pode ser exportado para PDF, por exemplo.

LearnCocos2D
fonte
1

Eu acho que o One Note é uma boa opção. É algo como um Wiki, mas com muito suporte a edição de rich text. Além do cliente de desktop padrão que acompanha o Office, há uma versão baseada na Web com o pacote Office Live . Honestamente, acho que a versão baseada na Web, que é gratuita, deve ser suficiente para a maioria das necessidades e, quando combinada com o Skydrive, você tem um sistema muito bom para colaborar em um documento ao vivo.

Alex Schearer
fonte
O evernote.com também é uma possibilidade para pessoas que desejam uma alternativa gratuita ao OneNote. Possui um cliente da Web e clientes para várias plataformas (desktops, telefones) e armazena todas as suas anotações "na nuvem". Eu acho que também possui recursos de colaboração, mas eles podem ser premium.
CodexArcanum 13/10/10
0

Para um dos meus projetos de código aberto, usamos o SharePoint (suspiro) para armazenar documentos e mídia. O gerenciamento de usuários e permissões é bastante simples e oferece suporte ao histórico completo da versão. Temos o site do SharePoint há cerca de quatro anos, portanto, pode muito bem haver opções melhores hoje em dia. No entanto, ele tem funcionado muito bem para nós. Ele é hospedado por terceiros (por cerca de US $ 20 / mês), portanto, após a configuração inicial, praticamente não houve manutenção de nossa parte. Além de oferecer suporte a bibliotecas de documentos e imagens, o SharePoint tem suporte para o Wiki, embora não tenha certeza de quão bem ele se compara aos mecanismos Wiki mais populares.

Mike Strobel
fonte