Como você decide quando sua lista de recursos é longa o suficiente?

Eu sei um pouco sobre essa questão, mas acho que existem muitas opiniões diversas sobre o assunto?

Sei da perspectiva dos jogadores que mais opções são quase sempre boas. Mas por outro lado, se tiver mais jogadores, significa maior complexidade (meta-jogo) tanto para os desenvolvedores quanto para os jogadores.

No desenvolvimento, a complexidade e as restrições de tempo sempre andam de mãos dadas. Outra seria restrições de recursos e plataformas. Possíveis ramificações econômicas de reter para mais tarde às vezes também são uma razão.

Então, pelas pessoas que experimentam aqui, além do exposto acima, quando os recursos devem ser cortados ou lançados posteriormente?

Eu diria que é um processo de duas etapas para nós:

• Estabeleça os objetivos do jogo.
• Determine quais recursos nos ajudam a alcançar esses objetivos.

A lista de recursos é longa o suficiente quando esses dois pontos coincidem. Assim:

1. Estabeleça nossos objetivos - Descubra todas as coisas que queremos que o jogo faça para o jogador / revisor / quem quer que seja, e as declare de maneira mensurável. Por exemplo, com o nosso mais recente ( veja o vídeo de teste alfa aqui ), queremos fazer o seguinte:

• Recursos visuais: queremos que cada crítica mencione que os recursos visuais são incomuns e sexy, especialmente para um título independente. Isso é importante para nós, porque os jogadores costumam usar seus olhos como uma métrica rápida de qualidade (embora, é claro, seja apenas uma de muitas!), E queremos que isso os atraia.
• Exploração: Também queremos recompensar as pessoas por explorarem o jogo. Para colocar isso de forma mensurável, queremos que algo em torno de um quinto do tempo do jogo seja gasto fazendo pequenas coisas legais fora da jogabilidade principal. Isso é importante para nós porque (IMO), grande parte do prazer de um jogo está fora das áreas centrais esperadas (pensamos em como o clique nas peças do Starcraft nos diverte).
• Comunidade: queremos que todos falem pelo menos um amigo sobre o jogo.

2. Determine os recursos que nos ajudam a alcançar esses objetivos - Eles quase caem naturalmente fora do acima. Portanto, os recursos que correspondem aos exemplos acima podem ser assim:

• Visuais: Como um pequeno estúdio, se queremos visuais sensuais, não podemos enfrentar a EA ou a Sony com realismo. Então, para abordar o objetivo de visuais notáveis, uma das características do jogo é uma estética surreal. (A partir disso, podemos determinar de que ferramentas precisamos e assim por diante.)
• Exploração: Petiscos como corolário da ação do jogo caem fora disso. Em nosso título mais recente , apresentamos uma referência rápida à pesquisa questionável de Ryo por marinheiros em Shenmue . Era um descarte bobo, mas as pessoas gostavam e conversavam sobre isso!
• Comunidade: Estamos nos perguntando todas as maneiras de fazer um jogo que vale a pena mencionar para um amigo. Tornar divertido é o número 1, é claro. Mas também poderíamos recompensar os jogadores com um item ou nível especial se eles twittarem sobre ele. Pokemon fez valer a pena ter amigos para pegar o jogo - existem algumas criaturas que você só consegue interagir com outras pessoas.

Quando passamos por esse processo, ele nos ajuda a determinar:

• Quanto precisamos implementar para um produto mínimo viável ( MVP ).
• O que é mais importante, o que pode esperar e o que podemos abandonar por completo.
• Quando finalmente tivermos todos os recursos que precisamos.

Vale a pena notar que não cumprimos essas regras de maneira servil! Na maioria das vezes, algumas coisas incrivelmente interessantes acontecem como resultado da prototipagem no meio do projeto e do futuro geral. Especialmente para jogos pequenos como o nosso.

Complexidade não torna seu jogo divertido.

A combinação certa e o equilíbrio dos elementos de jogabilidade fazem. O jogador deve ser levado ao limite de seu nível de habilidade e ter uma sensação de domínio ao vencer desafios.

Sua lista de recursos deve mudar sempre que você sentir que a jogabilidade atual não é divertida. Essas alterações devem ser feitas dentro das restrições de orçamento / tempo. Certifique-se de que todas as alterações que você agrega valor ao seu jogo.

Além disso, protótipo cedo, não basta escrever uma lista enorme de recursos e assumir que tudo será divertido quando reunidos.

A perfeição é alcançada, não quando não há mais nada a acrescentar, mas quando não há mais nada a ser levado.

-- Antoine de Saint-Exupéry

Quando o tempo e o esforço necessários para incluí-los são maiores que o valor que eles agregam ao jogo .

Por exemplo, se você estava criando um jogo esportivo ou algo em que os jogadores provavelmente gostariam de mostrar suas habilidades, o multiplayer é obrigatório. Guitar Hero não seria o mesmo sem ele. No entanto, um jogo exclusivamente individual, no qual você chega do início ao fim por conta própria, após uma história ou enredo não precisa de vários jogadores. O sistema multiplayer de má qualidade no Grand Theft Auto San Andreas é uma prova disso (mesmo que a empresa provavelmente não tenha achado o multiplayer muito difícil).

Além disso, recursos que realmente não se encaixam com a história do jogo, existem apenas porque podem estar. Se não é completamente essencial para o jogo, é provavelmente um bom sinal de que eles podem ser enviados para uma versão posterior, se o tempo for um problema.

O fato é que recursos extras não são o elemento essencial de um jogo. Uma história emocionante combinada com uma jogabilidade agradável é.

Embora exista um grau em que a variedade de recursos seja ótima (poder fazer toneladas de coisas aleatórias em um jogo GTA-ish, ter toneladas de variedade de armas e acessórios em um jogo de RPG ou Call of Duty etc.), Acho que uma jogabilidade mínima, focada em alguns recursos principais, pode ser altamente eficaz.

Olhe para o Portal, ele usou seu mecanismo principal e realmente construiu seus quebra-cabeças de maneira eficaz, sem precisar de muita confusão extra.

Eu acho que ser rigoroso em manter a lista de recursos o mínimo possível e realmente desenvolver alguns recursos principais permite um projeto mais viável e, muitas vezes, uma experiência mais agradável (se o Portal adicionou elementos de RPG e sequências de direção e slowmo e outros recursos interessantes) ", teria sido tão bom? A mecânica central teria sido tão polida?).

Agora, como um desenvolvedor independente, certamente sou tendencioso, mas acho que geralmente "menos é mais" em recursos, e mesmo que algo possa ser interessante ou popular no momento, se isso não tornar a experiência geral visivelmente melhor, deve ser cortado.

Descobri, por minha experiência pessoal, que é melhor evitar adicionar novos recursos não planejados o mais rápido possível.

Do ponto de vista do design, um recurso que foi adicionado durante um período do momento "não seria bom ter o recurso x" adicionará muito tempo de desenvolvimento, pode não se integrar bem ao código e pode não ajuste completamente com o resto do seu design.

Na pior das hipóteses, um projeto que teve muitos desses momentos pode parecer uma combinação de recursos desarrumados e hackeados, que realmente deveriam ter gastado muito mais tempo com eles na fase de design e parecer menos profissionais.

Como orientação geral, tento seguir estas regras:

• Se um novo recurso aparecer no início do projeto, reserve um tempo para voltar à fase de design e realmente veja como esse recurso pode funcionar com o seu produto, mantendo a consistência com o restante do design.

• Se o projeto estiver mais próximo do lançamento, considere fazer uma lista de recursos para adicionar a uma nova versão.

• Se você achar que muitos recursos continuam surgindo e que você realmente deseja implementar, talvez deva considerar voltar ao design e analisar por que esses novos recursos não foram considerados anteriormente, possivelmente devido à falta de esforço a fase de design.

Obviamente, isso se encaixa melhor em alguns projetos do que em outros, mas, na verdade, se um recurso aparecer no final do projeto, você provavelmente ficará bem sem ele, pelo menos até começar a trabalhar em uma nova versão.

Mantenha as listas curtas, seja ágil

Não crie listas de recursos ou, se for o caso, crie-as muito curtas, valendo apenas algumas semanas de desenvolvimento.

Desenvolva em estilo ágil - comece com os poucos recursos mais importantes, teste com base no que funciona e no que não funciona e, em seguida, pense se vale a pena adicionar mais alguns recursos (você poderá julgá-los muito melhor se você já tem alguma experiência com a jogabilidade básica).

Como julgar uma característica individual

Fora isso, eu concordaria com o critério bennybdbc: "Quando o tempo e o esforço necessários para incluí-los forem maiores que o valor que eles agregam ao jogo".

Dito isto, você também precisa considerar o mundo "externo":

• você está ficando sem dinheiro ou sem tempo determinado por um contrato?
• você está ficando sem espaço para mídia de publicação (DVD cheio)
• você está ficando sem espaço de desempenho (novos recursos causariam uma lentidão no jogo)?
• um jogo competitivo será publicado em breve?

Questões simples da vida real como essas também precisam ser consideradas, a menos que você esteja desenvolvendo o jogo apenas para se divertir.

Quando você ficar sem papel para escrevê-lo.

O limite definido será o tamanho da mídia; você não pode caber 10 GB de recursos em um DVD de 4,7 GB, por exemplo.

Você também não quer muitos recursos para complicar demais o jogo. A melhor maneira é pensar 'isso será significativamente divertido para o jogador? isso vai consumir muito o nosso tempo de desenvolvimento? isso é possível?