Que tipo de gerenciamento de projeto um projeto de desenvolvedor solo deve usar?

Estou trabalhando sozinho em um projeto de jogo cujo desenvolvimento pode ser separado em três partes independentes (geração de mapas, o mecanismo do “mundo superior” e o mecanismo de batalha), mas, à medida que o desenvolvimento avança, não tenho certeza de como devo lidar. a gestão deste projeto, especialmente em relação a esses 3 pontos:

1. Vale a pena usar um sistema de controle de versão, já que estou trabalhando sozinho?

2. Devo usar um método formal para registrar os recursos / bugs planejados (apenas lembro o que precisa ser feito por enquanto)

3. A pergunta mais importante: como posso saber o que desenvolver primeiro? Agora que o básico está pronto, conheço a lista de recursos a codificar, mas não sei em que ordem devo fazê-lo.

Eu usaria:

1. Gerenciamento de código

GIT (e a incrível referência ), um gerenciador de código-fonte distribuído, para gerenciar meu código e hospedá-lo no GitHub como um projeto privado, se eu quiser mantê-lo fora dos limites.

(Existem muitas opções aqui, apenas o google para gerenciamento de código-fonte, você nem precisa usar o GitHub ou qualquer outro site, o Git funcionará perfeitamente no seu computador local, mas o uso do GitHub fará com que o gerenciamento de backups ocorra. Muito mais fácil.

Se você tiver dois computadores, poderá criar um repositório em um que chamará de sua máquina de backup e cloná-lo na rede local e usá-lo para desenvolvimento. Quando terminar um recurso, você pode enviá-lo para o diretório máquina de backup e você terá um backup 1: 1!)

2. Gerenciamento de problemas e recursos

Eu usaria o gerenciamento de problemas interno do Trello ou do GitHub para rastrear bugs e coisas a fazer.

3. Tenha um processo de design

Eu projetaria meu jogo primeiro;

1. primeiro em minha mente,
2. depois no papel
3. então provavelmente use o GameMaker ou o PyGame para criar um protótipo da minha ideia e repita de 1 a 3 até que eu tenha algo que goste de jogar.

4. Use meu protótipo como guia e desenvolva meu jogo

Então eu colocaria meu protótipo de lado e escolheria uma plataforma para a qual gostaria de desenvolver. Procure os mecanismos existentes e escolha o que melhor se adequa à minha ideia de jogo. Depois, estabelecia metas claras para o meu projeto, estruturava-as em pequenas tarefas e começava a trabalhar para concluir as tarefas. Quando você atingir esse estado, provavelmente descobrirá que tem seu próprio modo de trabalhar que melhor combina com você, então continue com isso!

Existem várias metodologias / filosofias diferentes que você pode aplicar em seu estilo de desenvolvimento, XP, Waterfall, etc. Basta seguir a que você sente que progride o mais rápido.

5. Tenha muitos testadores de jogos!

Quando você tiver algo jogável, peça a seus amigos imediatos para experimentá-lo! Torne mais fácil para eles ajudá-lo, configurando pacotes de instalação rápida, se estiverem executando o Windows ou gravando algum script de shell que possa automatizar o processo para eles, se estiverem usando Linux / Mac. Tome muito cuidado com o feedback dos seus testadores e não se esqueça de informá-los sobre o design do jogo e que tipo de jogo você está tentando criar.

6. Crie um site para o meu jogo

Assim que eu tiver algo indo bem, provavelmente criaria um site para o meu jogo - para manter minha criatividade e conteúdo fluindo quando não puderem ser aplicados ao progresso do meu jogo, por exemplo, se estiver focando meus estudos ou precisa de uma pausa no desenvolvimento!

Se eu usar o GitHub , eu configuraria uma página de projeto para o meu jogo, caso contrário, hospedaria um blog WordPress / Jekyll ou algo semelhante e escreveria minhas postagens com isso.

Isso manterá você motivado, além de ter um lugar para indicar jogadores / testadores em potencial!

7. Participar de concursos

Há muitos concursos de desenvolvedores de jogos acontecendo quase o tempo todo. Eu tentaria juntar um desses ao meu jogo se as regras permitirem. Isso aumenta a motivação e torna tudo ainda mais divertido - quem não gosta de ganhar!

(Se você estiver desenvolvendo dentro de um prazo estrito, poderá ignorar este ponto pelo menos.)

Eu sugeriria fortemente o uso de um sistema de controle de versão, mesmo se você trabalha sozinho. Isso pode economizar muito tempo, uma vez que você exclui acidentalmente algo ou faz uma alteração maior, apenas para perceber mais tarde que era uma péssima idéia e é necessário desfazer todas as alterações.

Edit : Existem muitas soluções de controle de fonte gratuitas.

• Eu usei o servidor VisualSVN , que é fácil de configurar e usar no Windows.

• Também existem alternativas on-line como Codeplex (com SVNou Mercurial), SourceForge ou Google Code . A vantagem é que você não precisa configurar e manter um repositório e seus dados estão na nuvem; o problema é que você não pode hospedar livremente projetos de código fechado.

Quanto ao rastreamento de bugs e recursos: se você já tem um público maior que possa estar interessado em testar seu jogo beta, reportar bugs e solicitar recursos, vá em frente.
Se, no entanto, houver apenas algumas dessas pessoas (ou nenhuma), isso é desnecessário.

E quanto às prioridades de desenvolvimento - é você quem decide. Quem deve saber melhor o que fazer em um projeto do que seu único desenvolvedor?

Vale a pena usar um sistema de controle de versão, já que estou trabalhando sozinho?

Acho que sim. É muito fácil de configurar e já tive várias vezes que enlouqueci com a refatoração ou fiz algo estúpido, e a capacidade de reverter minhas alterações economizou muito tempo. Além disso, se estiver hospedado em um servidor, você terá um backup do nosso código, caso algo dê errado .

Devo usar um método formal para registrar os recursos / bugs planejados (apenas lembro o que precisa ser feito por enquanto)

Eu não acho necessário. Eu manteria uma lista escrita do que você pretende fazer, apenas para garantir que você não esqueça de um bug menor, além disso, acho que ajuda você a começar de novo depois de fazer uma pausa na codificação.

A pergunta mais importante: como posso saber o que desenvolver primeiro? Agora que o básico está pronto, conheço a lista de recursos a codificar, mas não sei em que ordem devo fazê-lo.

Pegue a lista acima, feche os olhos e cutuque-a aleatoriamente. Trabalhe em qualquer recurso em que seu dedo esteja. A menos que os itens dependam um do outro, é mais importante apenas manter o fluxo do que garantir que as coisas aconteçam em uma ordem específica.

Definitivamente use o controle de versão

O controle de versão é como uma rede de segurança para um equilibrista: libera você para tentar coisas malucas. Um grande refatorador que exclui grandes pedaços de código não é problema se você pode reverter facilmente. É ainda menos se você estiver em um ramo experimental do seu repositório e puder decidir não mesclá-lo novamente.

Se você não tiver esse tipo de liberdade, provavelmente deixará um código comentado em qualquer lugar, com medo de precisar dele.

Eu votaria no Git. A sintaxe é um pouco estranha, mas duas grandes coisas são:

• Baixa sobrecarga . Mude para uma pasta e digite git inite você está pronto para começar a fazer o check-in. Se você decidir que não quer controlá-lo, afinal, rm -rf .gitnessa pasta e não é mais um repositório Git.

• Distribuído via SSH . O Git é distribuído, o que significa que você pode ter várias cópias completas do seu repositório (todo o histórico etc.) em vários lugares e mantê-las sincronizadas. Você pode configurar outro repositório Git em qualquer máquina em que tenha acesso SSH e adicionar esse outro repositório como um controle remoto. Depois disso, a qualquer momento, você deseja fazer backup apenas git pushdesse repositório.

  Essa é uma grande vantagem sobre, digamos, o Subversion, onde todo o repositório reside em uma máquina e essa máquina precisa estar executando um servidor Subversion.

O Mercurial pode ter esses mesmos pontos a seu favor, mas eu não o usei.

1. Sim! Como você está perguntando, acho que você é bem adotado com o sistema de controle de revisão. É obrigatório!

2. Em relação à sua segunda pergunta, há um método formal de registro de bugs e você deve usá-lo. Para os recursos de planejamento, acho que seguir uma rota menos formal não será prejudicial (quando você estiver trabalhando sozinho)

3. Faça primeiro esses recursos que darão vida ao seu jogo. Dê uma idéia de como será o jogo final.

1) Sim, claro. Eu recomendo o Mercurial via BitBucket e TortoiseHg. O BitBucket é gratuito para até 5 usuários e, uma vez que está hospedado na nuvem, adiciona um pouco de tranquilidade (sem necessidade de backups).

2) Os erros devem ser corrigidos antes da implementação de novos recursos. Eu usaria uma lista TODO simples e acessível para rastrear coisas - pendentes / concluídas. Você pode apenas usar um arquivo de texto simples, mas não se esqueça de adicioná-lo ao seu repositório de controle de origem.

3) Faça o que você quer fazer em um determinado dia, mas lembre-se de que oferecer algo reproduzível pelo usuário final é o objetivo principal. Por exemplo, se você está cansado de acertar a física, trabalhe na renderização ou talvez adicione alguns testes de unidade ausentes para essa IA.

Pedaços de trabalho devem ser pequenos o suficiente para serem feitos em alguns dias. É crucial manter-se motivado e evitar o cansaço.

Se a arquitetura for feita corretamente, você poderá adicionar facilmente partes modificadas do mecanismo / jogo sem afetar várias outras (caso contrário, comece com alguma refatoração :).

1) Como todo mundo diz: SIM (eu diria, alugue um barato online)

2) Mantenha uma lista simples ou, se o seu projeto crescer muito e você obtiver testadores beta, instale o Mantis Bug Tracker

3) Não sei, mas vou lhe dizer como faço: desenvolva as coisas menos interessantes e / ou mais difíceis primeiro. Repita até que tudo esteja pronto. Dessa forma, o desenvolvimento fica mais engraçado e fácil (e você não vai encontrar esse problema, simplesmente não pode resolver tarde demais, se é que isso aconteceria).

Obrigado por fazer esta pergunta. É exatamente isso que estou fazendo atualmente.

1) Controle de versão: É necessário. No momento, estou mantendo o backup manual. É útil pelo menos quando algo que estava funcionando muito bem de repente gera erros (ou não funciona como esperado). Comparo versões e frequentemente encontro erros bobos (principalmente comentando algo)

2) Criei um documento do Word e listei todos os recursos que meu jogo terá em uma ordem categórica e com recuos em vários níveis listando sub-recursos (relacionados ao cliente / servidor ou o que for aplicável).

3) Após a lista que recebi (que geralmente não é completa, sempre acrescenta algo a ela), penso no meu fluxo de jogo e realce todos os pontos necessários para que eu faça o jogo rodar e comece a fazê-lo. Eu marco amarelo, significando trabalho em andamento. verde quando concluído. laranja para indicar que está melhorado ou tem alguns erros conhecidos

espero que isto ajude

1.) Vale a pena usar o controle de versão para qualquer projeto. Mesmo os muito pequenos, se você já sabe como usá-lo. Eu uso o Subversion há anos no Linux e Windows com o TortoiseSVN . Mesmo ao criar um projeto pequeno (<500 linhas), criarei um repositório para ele para desfazer alterações, acompanhar o que estava fazendo se abandonar o projeto por um tempo etc.

2.) Depende do tamanho do projeto. Se você planeja testar com uma equipe e distribuir, provavelmente vale a pena ter um sistema de rastreamento de bugs. Atualmente, estou trabalhando sozinho (embora eu tenha um artista) em um projeto com mais de 20 mil linhas, e apenas mantenho minha lista de tarefas em um arquivo de texto que também está no meu repositório SVN. Embora eu ainda não tenha exatamente a necessidade de compartilhá-lo com outras pessoas, a falta de rastreamento de bugs se ajusta às minhas necessidades no momento. Eu não iria me preocupar com isso até que haja uma necessidade. O pior que pode acontecer é que você precisará inserir os bugs que você já anotou e remover / revisar os que corrigiu. Quando você começar a perder o controle mental de suas anotações, obtenha um rastreador de erros.

3.) Coloque no papel. Comece com o que você quer que seu jogo acabado seja, anote a essência dele. Em seguida, divida-o no que será necessário para torná-lo: detecção de colisão? código de rede? tipos de jogadores e monstros? hierarquias de classe? Trabalhe para trás a partir de sua visão, para ter uma idéia clara de como construí-la desde o início. Presumo que você esteja usando uma linguagem orientada a objetos. O passo mais crucial para começar seria configurar essas hierarquias de classe de maneira sensata. Tente o máximo possível para não ter absolutamente nenhuma herança múltipla (embora às vezes seja inevitável), plote as relações de classe em um editor de diagramas (eu uso Dia ), etc. Os princípios básicos ajudam bastante a evitar dores de cabeça mais tarde.