Por que projetos indie não vivem para lançar

Recentemente, mais uma vez tentei participar de um pequeno projeto independente.
Fiz um protótipo com gráficos primitivos, o segundo parceiro deveria fornecer gráficos aprimorados, mas não consegui e, como um todo, decidi escrever um pequeno artigo sobre o porquê realmente quero, mas não dá certo. O artigo tem muita trivialidade, mas pode ser útil para alguém.

1. Datas


Sim, e sim novamente, tudo voa com o tempo, de pequenos a grandes desenvolvimentos, porque obter uma jogabilidade de alta qualidade é muito difícil, e muito tempo é gasto em refazer recursos e jogabilidade. Mas a raiz do mal é freqüentemente armazenada precisamente na estimativa inicial do tempo.

Pegue um protótipo simples de clicker - toque na tela, o herói acerta o monstro com uma espada e habilidades. Tudo é super simples, a maioria dos desenvolvedores, tendo estimado a escala do protótipo, dirá que essa tarefa pode levar de várias horas a um dia / casal.

Mas! Vamos calcular cuidadosamente a quantidade mínima de trabalho:


Código

  1. Sistema de interface (você precisa exibir todas as informações necessárias)
  2. Carregamento nivelado
  3. Carregando / puxando gráficos (o jogo pode ter muitos efeitos / recursos reutilizáveis)
  4. O personagem principal e suas habilidades
  5. O inimigo
  6. Sistema de ataque
  7. Sistema de passagem de nível (a dificuldade deve aumentar e os gráficos de nível devem ser coletados)
  8. Sistema de pontos
  9. Sistema de atualização de jogadores (habilidades e bônus do nível)
  10. Sistema de som
  11. Sistema de acumulação / despesa de recursos (um jogador pode ter habilidades para mana ou gatilhos)
  12. Sistema de armazenamento de dados do player (o progresso deve ser armazenado)

Interface

Mesmo para um protótipo, é necessária uma interface mínima, mas se estamos considerando um protótipo / PoC (prova de conceito), é desejável ter um design delicioso e um UX normal. O mínimo que você precisa:

  1. Menu principal
  2. interface de combate (com escalas de saúde, exp, nível de progresso, escalas de mana, habilidades de cobrança, etc.)
  3. pop-up sobre a vitória na rodada atual
  4. pop-up sobre a perda
  5. poplap sobre lvlapa
  6. interface de atualização do jogador

Gráficos e animação

Há mais ou menos claro

  1. Gráficos de pelo menos três inimigos
  2. Os gráficos do personagem principal
  3. Gráficos para gerar níveis
  4. animação gráfica de nível
  5. Para cada habilidade você precisa de animação (aqui você precisa multiplicar pelo número de habilidades).
  6. É necessária animação para ataques básicos (deve haver muitas variedades de ataques básicos para que o usuário não fique entediado de olhar para o mesmo golpe de espada)
  7. Animação de vitória de personagem
  8. Animação de Perda de Personagem
  9. Animação de ataque inimigo
  10. Animação de obter dano pelo inimigo
  11. Animação inimiga semi-morta
  12. Morte inimiga

Efeitos especiais

  1. indicação de dano (todos os tipos de tsiferki, agitação, avermelhamento da tela)
  2. aplicação de habilidades (para cada habilidade)
  3. indicação de dano (sangue / faísca / fumaça)

Sons

Basta olhar para as listas anteriores e adicionar sons a toda a gráfica, interface e efeitos especiais. Leva muito tempo.

Para que servem todas essas listas?


Para mostrar o volume principal que você precisa pôr em marcha para obter pelo menos algum protótipo jogável, que pode ser chamado de jogo. Não levei em consideração a localização e muitos outros trabalhos, mas a principal idéia que quero transmitir é a quantidade principal de trabalho.

Eu criei uma regra pequena - mesmo uma tarefa pequena pode levar de uma hora a duas. Muito poucas pessoas estão envolvidas no desenvolvimento indie em tempo integral. Muitos dos quais eu sei combinam com o trabalho completo. Ou seja, o desenvolvimento indie leva apenas tempo livre à noite; para mim, são cerca de 2-3 horas, acho que a maioria também. 1+ tarefa fácil por dia. Uma tarefa complexa pode levar vários dias. Nem todos os dias, ele acaba trabalhando em um projeto por várias razões. Como resultado, o volume nas listas acima já é de mais de um mês de trabalho, apesar de tudo estar indo bem e de todos os profissionais. E este é apenas um protótipo. E então você precisa de um sistema mais complexo de atualizações, ainda mais gráficos, que traga um equipamento diferente que afete os ataques / habilidades / hp / heróis contratados, contratando heróis para ajudar o jogador, diferentes modos de jogo.

O desenvolvimento de um bom protótipo de um clicker super simples pode levar um ou dois meses, extremamente fácil, embora, como escrevi acima, à primeira vista, trabalhar lá por alguns dias seja o máximo. E se você tomar beta, pode demorar um ano. Atrasar o processo frustra e as pessoas começam a cair. Isso é fornecido para todos os desenvolvedores menos experientes. E então vamos ao ponto 2.

2. Competências


Infelizmente, um bom programador não significa um bom desenvolvedor independente, assim como um bom artista / modelador / animador, etc. Existem muitos iniciantes no desenvolvimento indie, e um excelente artista que desenha muito bem pode não ser capaz de preparar adequadamente os gráficos para o mecanismo usado. Haverá muitos erros, reimportação, reconfiguração, reanimação e muitos erros relacionados à importação de gráficos distorcidos.

Quanto aos programadores - um excelente programador de C # que não conhece o Unity3d escreverá várias de suas bicicletas e soluções que duplicarão a funcionalidade do Unity e não o fato de que eles funcionarão bem. Porque o paradigma de programação em sharpe puro e dentro da unidade é bastante significativo.

Além disso - se algo das listas acima for feito pela primeira vez, levará um tempo para revisar, o que novamente multiplica o tempo de desenvolvimento. Portanto, no final, mesmo tarefas simples não levam um dia, mas três. E, novamente, temos um longo período de tempo. Para queimar jovens, essa será uma experiência necessária e, para veteranos, será outra decepção.

3. Resumo e dicas


Os resultados são simples - mesmo um projeto pequeno se transforma facilmente em uma construção de longo prazo, as pessoas queimam quando não veem um resultado fervoroso, o projeto se funde em uma cesta.

Portanto:

  1. Avalie com cuidado a quantidade real real de trabalho, geralmente onde você pensa que trabalha um dia, pode haver trabalho por 1 mês em equipe, quando tudo isso se prolongar - a equipe pode não se sustentar e desmoronar
  2. Tente acumular e reutilizar soluções, não se trata apenas de conquistas, mas também de materiais de treinamento
  3. O protótipo primário pode ter um mínimo de gráficos, mas os gráficos devem ser animados o suficiente para gostar do protótipo - você precisa de animações e efeitos. Deve haver exatamente tantos gráficos - para gostar e sentir a própria jogabilidade.
  4. Lidere o desenvolvimento publicamente, publique o progresso do projeto na comunidade e nos fóruns, interrompa a tarefa para que o resultado seja mais óbvio. Isso criará esse mesmo sentimento do movimento correto de um projeto vivo. E a equipe entenderá que seu trabalho não é em vão.

Quanto às dicas - ficarei feliz em ouvir a sua, a experiência de mover um projeto independente para o lançamento é interessante. Do ponto de vista da organização do processo.

Source: https://habr.com/ru/post/pt452856/


All Articles