Design de jogos para dispositivos móveis: iteração vs. planejamento e perigos do MVP

Para todos os designers de jogos que não estão planejando, eu gostaria de dizer:
“Pare! Você é perigoso. Vocês são desenvolvedores cansativos. Você está desperdiçando tempo e recursos valiosos que poderiam ser facilmente economizados prestando atenção suficiente ao planejamento. A criação de design se transforma em atrasos no desenvolvimento geral. A pressa de se espremer em novos recursos incompletos voltará para você na forma de despesas não planejadas. Funciona bem!

Como é feito o planejamento da qualidade?

Como regra, o design de jogos para dispositivos móveis é dividido em duas escolas básicas de princípios de desenvolvimento:

1. Iteração - estabeleça a mecânica básica e depois repita até que algo que valha a pena seja obtido; rascunho do projeto antes de seu desenvolvimento.
2. Planejamento - pense cuidadosamente sobre cada recurso, cada janela, todas as dependências e interações entre os principais recursos antes do início do desenvolvimento.

Geralmente, os adeptos da escola de iteração vêm do mundo dos PCs, onde as pessoas estão acostumadas a vender os jogos mais interessantes para o usuário na configuração básica por uma taxa única fixa. Esses jogos geralmente têm uma alta taxa de retenção de jogadores e baixa monetização.
Na minha opinião, há muitas pessoas que se deixam levar pelo método de iteração. Essas pessoas elevaram o MVP (produto mínimo viável em inglês) ao status de um culto e fizeram do método MVP uma muleta universal e uma desculpa barata para não pensar em todos os recursos com muito cuidado. Os proponentes da abordagem MVP geralmente apresentam argumentos como:

• "Podemos executá-la mais tarde".
• "Pensaremos em monetização mais tarde, mas por enquanto precisamos fazer algo interessante".

Infelizmente, desenvolvedores não técnicos não entendem que o código do jogo não é de borracha. Não é para você montar blocos de plástico LEGO. O jogo não é plasticina, não pode ser fortemente redesenhado sem consequências significativas. Isso ocorre porque o código (especialmente o código do jogo com uma quantidade razoável de código rígido) é relativamente inflexível.

A esse respeito, tenho um ponto de vista bastante radical: acredito que muitos designers de jogos que usam o método de iteração em jogos móveis gratuitos são simplesmente perigosos porque equipes de desenvolvimento inteiras podem arruinar sua preguiça.

No novo mantra para o desenvolvimento de jogos para celular, não devemos falar sobre MVP com ênfase no "mínimo" para o desenvolvimento de um produto viável, mas em algo mais.

Lei de Kim:

desenvolva um produto minimamente sustentável com o planejamento mais sustentável

A indústria de jogos para celular é muito dura para pessoas que não querem investir tempo e esforço no planejamento de seus projetos.
Muitas vezes, vejo os seguintes tipos de eventos:

• Idéias semi-brutas e insuficientemente pensadas são dadas ao desenvolvimento.
• Muitos desenvolvedores, em busca de tendências e designs de jogos mais lucrativos, colocam recursos nos jogos existentes que parecem extremamente ridículos por lá.
• A interação dos recursos e sua influência um no outro no jogo não é bem pensada.

Para todos os designers de jogos que se enquadram nessa categoria, eu gostaria de dizer:

“Pare! Você é perigoso. Vocês são desenvolvedores cansativos. Você está desperdiçando tempo e recursos valiosos que poderiam ser facilmente economizados prestando atenção suficiente ao planejamento. A criação de design se transforma em atrasos no desenvolvimento geral. A pressa de se espremer em novos recursos incompletos voltará para você na forma de despesas não planejadas. Funciona bem!

Como é feito o planejamento da qualidade?

De fato, tudo se resume às seguintes tarefas básicas:

1. Interface do usuário. Verifique se a interface suporta seu recurso. Faça layouts das janelas principais com antecedência.
2. Fluxo do usuário. Antes de dar um novo recurso ao desenvolvimento, verifique se todas as janelas e suas combinações no fluxo do usuário são levadas em consideração e pensadas. Que tipo de fluxo? Leia aqui: UI móvel e design de jogos: telas vs. Fluxos
3. Casos fronteiriços. Pense em todos os principais casos fronteiriços. O que é isso? Casos limítrofes são situações de jogo que estão fora do escopo do fluxo normal de jogo, mas também precisam ser resolvidas. Verifique se, em casos limítrofes, não há armadilhas.
4. Impacto no sistema.Pense em como um novo recurso afetará o equilíbrio e a economia do seu jogo. Como isso afetará outros sistemas no seu jogo. E em diferentes partes da interface? Verifique se não há contradições em lugar algum.
5. Impacto no projeto. Como um novo recurso afetará a jogabilidade, os parâmetros de design e a monetização? Se você adicionar imediatamente um novo recurso PvE a um jogo PvP, isso poderá levar a um desastre. Como isso afetará a monetização esperada e real? (Mais informações aqui: Design de jogos baseado em monetização: contribuição da ARPDAU ) Pense nisso!

Mas, ainda assim, há momentos em que é melhor usar uma abordagem iterativa em vez de planejar. Por exemplo, em experimentos com novos tipos de jogabilidade, se essa é a principal tarefa e o principal risco. Além disso, o ponto não está no planejamento TOP. Considere os problemas de design acima, tanto quanto necessário para cada recurso específico, tipo de jogo, seus objetivos, etc. É o seu caso específico que determinará seu Planejamento Sustentável Máximo. Não há solução padrão para todos os problemas.

Dependendo da situação, um planejamento mais cuidadoso, como regra, requer os seguintes tipos de jogos:

• Mais complexo - complexo, multi-sistema, com um grande número de relacionamentos; aqui você precisa entender como um novo recurso afetará todo o resto do jogo.
• Mais interface do usuário - também mais complexa, mas em termos de um grande número de janelas;
• Multissistema - quanto mais difícil o seu jogo, mais sistemas ele possui.



Para concluir:

• Espero que esta publicação ajude um de vocês a aumentar as chances de sucesso do seu produto através do planejamento.
• Você precisa entender quando usar o planejamento situacionalmente e quando usar a iteração.
• Use as técnicas acima para reduzir as iterações de produção; a parte principal do planejamento deve ser realizada nos primeiros estágios do desenvolvimento do jogo, quando o custo das mudanças ainda é relativamente pequeno.

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