Estou em pré-produção em um jogo de estratégia e estou tentando determinar se a jogabilidade principal será divertida. Uma boa técnica para determinar isso é reduzir o jogo ao seu produto mínimo viável (MVP) e ver se isso é divertido. Se o MVP não for divertido, nenhuma quantidade de conteúdo ou recursos extras o tornarão divertido.

Estou tendo dificuldade em determinar o MVP para um jogo de estratégia, pois estou um pouco longe demais para ver quais dos muitos recursos de design são mecânicos essenciais e quais são desnecessários.

Apenas como exemplo, digamos que StarCraft2 é o jogo de estratégia que eu quero fazer. Qual seria o MVP do SC2 para provar que sua jogabilidade principal é divertida?

Estratégia em tempo real é um gênero que realmente combina vários jogos em um. Você tem um jogo de gerenciamento (gerenciamento de recursos e ordens de construção), um jogo de quebra-cabeça (construindo uma base com um layout funcional e fácil de defender), dois tipos diferentes de jogos de exploração (explorando o mapa e explorando quais unidades superam outras unidades), e um jogo de táticas (controlando suas unidades na batalha). Obviamente, você não pode criar todos esses cinco jogos ao mesmo tempo; portanto, concentre-se em um deles primeiro.

Nesta resposta, estou focando em dois desses jogos que considero mais essenciais para o gênero: controle de unidade e construção de base.

MVP de controle de unidade

1. Crie um objeto de jogo "tanque" controlado por jogador (representado como um cubo não texturizado) em um plano vazio que se move para uma nova posição quando o jogador clica nele.
2. Adicione alvos de AI imóveis (representados por um cubo em uma cor diferente) que serão excluídos quando o HP deles for inferior a 0 e a capacidade do tanque de disparar no alvo mais próximo para reduzir o HP.
3. Adicione a capacidade de os alvos dispararem quando o tanque-jogador estiver ao alcance.

Agora você tem um jogo de estratégia / quebra-cabeça jogável: Navegue pelo seu tanque de alvo em alvo de uma maneira que ele não lute mais de um por vez e destrua todos eles antes que ele seja destruído. É basicamente assim que você ataca uma base com torres defensivas em um jogo RTS.

Próximas etapas a serem seguidas em nenhuma ordem específica:

• Adicione uma IA simples aos oponentes para que eles possam se mover e não apenas revidar
• Adicione várias unidades de jogador ao controle e a interface do usuário para selecionar unidades
• Adicione construções (consulte "MVP de construção de base" para obter detalhes)
• Adicione mais tipos de unidades com diferentes alcances, pontos fortes da arma e pontos de vida
• Adicione um terreno bloqueador ao mapa e encontre a rota para a unidade AI para que eles possam navegar ao redor.
• Substitua as unidades por gráficos adequadamente animados
• Adicione condições de ganhar e perder

MVP de construção de base

1. Crie um plano vazio e permita que o jogador coloque um edifício nesse plano clicando em
2. Adicione diferentes tipos de construções e uma interface do usuário que permita ao jogador escolher qual construção construir
3. Adicionar tempos de construção e contadores de recursos
4. Adicione edifícios que criam recursos em intervalos regulares (eu ainda não implementaria unidades de trabalho porque elas exigem muita programação de IA para funcionar) e um conjunto de regras para quando você pode construir qual edifício ("só pode construir uma fábrica quando você tiver pelo menos um quartel terminado ").

Agora você implementou os primeiros minutos de um jogo Starcraft: Descobrindo a ordem de construção ideal para obter os edifícios que você deseja o mais rápido possível.

Na verdade, você pode ficar aqui e polir, e você tem um jogo simples de gerenciamento de recursos. Mas se você ainda tiver certeza de que deseja criar um RTS, as próximas etapas não serão em uma ordem específica:

• Adicione uma IA que construa seus próprios edifícios
• Adicione recursos de terreno que impeçam a construção de edifícios (ou são um requisito para a colocação de determinados edifícios, como "fazendas só podem ser construídas em terrenos férteis")
• Adicione unidades móveis (consulte "Unit Controlling MVP" para obter detalhes) que podem destruir edifícios inimigos
• Adicione trabalhos de construção a edifícios individuais que possam ser iniciados, levem um certo tempo para serem concluídos e podem ser abortados pelo jogador.
• Crie tipos de construção que interagem entre si de alguma forma (em Starcraft, seriam addons terráqueos ou postes Protoss, por exemplo)

Estou ansioso para jogar o seu jogo.

Qual seria o MVP para SC2 ...?

Se a resposta fosse geralmente conhecida, você não acha que haveria muito mais concorrência com o SC2 por aí? O SC2 é o produto de inúmeras horas de decisões de design; todos os patches lançados no SC1, o design inicial do SC1, as lições do WC e WC2 que entraram no design do SC1 e assim por diante.

Design de jogos não é uma ciência exata. O design de jogos está trabalhando com infinitas possibilidades. Claro, existem recursos bastante padrão no RTS, mas a questão aqui não é O que é um RTS para todos? porque todo mundo não está construindo seu jogo, você é. Então é melhor, o que é um RTS para você? (e porque?)

Analisar o trabalho de outras pessoas é importante; mas começar seu próprio trabalho é muito mais importante. Pesquisa é importante; mas não deixe isso te atolar. Comece a criar diversão.

MVP é uma idéia brilhante, mas você está perdendo o espírito dela: os MVPs são sobre prototipar ativamente suas idéias, não sobre pensar demais no seu e no trabalho de todos os outros. Sujar as mãos é mais importante do que se preocupar com a suposta mecânica mínima para um RTS. Muitos jogos podem ser considerados RTS, que caem amplamente fora da definição usual desse gênero. Faça uma demonstração e faça com que as pessoas comecem a reproduzi-la; e eles decidirão se o seu produto é viável e também o gênero.

Estou um pouco longe demais para ver

Até o início da criação de protótipos, esse será o caso, e muitas perguntas permanecerão difíceis de responder.

Alguns aspectos que eu diria são bastante fáceis de decidir o que você precisa para um RTS em geral. Dependendo do seu conceito, você precisa de uma "unidade", que pode ser montada, ordenada ou o jogo apenas começa com ela.

Começando com Starcraft como exemplo, implemente talvez uma unidade de trabalho, um prédio e uma unidade de combate. Seu prédio deve ser capaz de construir os dois. Geral: eu nem adicionaria um recurso para colher, mas como o Starcraft depende muito dele, nesse caso, você deve fazer isso.

A parte difícil é que recursos você precisa implementar também. Sua unidade de combate precisa ser capaz de "lutar". Então ele pode atirar? ele pode atacar no cc? Quais são os inimigos? Você precisa de mais unidades diferentes (por exemplo, ar?)

Sim, você deve começar apenas com uma corrida, para ter basicamente apenas jogos de espelhos, por assim dizer. Além disso, você não precisa de um mapa (se isso não atrapalhar nenhum recurso muito importante), apenas um quadrado para seguir em frente. Qual é o objetivo? Destruição do inimigo ou pontos de vitória, controlando pontos de captura?

Eu acho que o problema com o RTS é que você basicamente possui tantos recursos importantes e elementos básicos que ainda precisa implementar para ter um MVP, embora seja realmente difícil dizer quais são os elementos principais de seus jogos.

Na minha opinião, tudo se resume a comparar o seu jogo base com outros RTS, e existem muitos deles, e mesmo continuando em uma sequência, eles não são os mesmos.

• C&C Tiberium e Red Alert Series: começando com o edifício principal, construa edifícios por menu sem uma unidade de construção, construa unidades no menu quando existir um edifício correspondente, diferentes tipos de unidades individuais (a pé, veículo terrestre ou aéreo)
• Dawn of War 1 & 3, Company of Heroes: edifício base com unidades de construção, sem coleta de recursos ativos (geração passiva por pontos de controle), a maioria das unidades é baseada em grupos
• Battlefleet Gothic: Sem edifícios, sem recursos, diferentes tipos de unidades, não substituíveis, as habilidades são extremamente importantes

Todas essas diferenças tornam os RTSs muito diferentes. Tentar reduzir o jogo a esses princípios é muito mais complicado do que o exemplo que o Extra Credit deu nos jogos de corrida: acelerar blocos, colisões, é isso.

O que torna seu jogo único

O principal motivo para o desenvolvimento de um MVP é que você pode testar sua ideia com antecedência e liberar, se necessário. Ou seja, você garante que sempre termine o desenvolvimento com um "algo", em vez de nada.

No entanto, isso não significa simplesmente criar a versão mais básica de um RTS possível. Significa criar a versão mais básica do seu RTS possível.

Descobrir exatamente quais recursos e ativos são necessários é uma arte em si. No entanto, seu objetivo deve ser o de minimizar a recriação de coisas que você sabe que funcionam e a inclusão de tantas coisas que você não sabe. Ou seja, você deve incluir apenas itens genéricos para outros jogos - se precisar testar adequadamente suas idéias específicas:

• Você precisa de IA sofisticada? (Para um MVP de um nível, você pode se safar apenas de uma ordem de construção fixa que a oposição sempre usa.)

• Você precisa de mais de uma facção? (Talvez o seu jogo se concentre na sinergia entre duas raças e isso é fundamental. Mas talvez seja realmente apenas um "prazer em ter")

• Você precisa ter construção de unidade e recursos? (Talvez tudo o que você precise é de uma cena de batalha pré-fabricada com um número definido de unidades, talvez todas as suas ideias-chave estejam realmente focadas no lado das habilidades e táticas)

• Você precisa ter o multiplayer? (Se o objetivo do jogo é fazer um MMORTS para 6000 jogadores; então sim - você provavelmente faz)

É claro que isso também inclui recursos de arte:

• Você realmente precisa que ele seja executado em 3D? (talvez você tenha recursos de terreno não plano)

• Você realmente precisa de vários modelos de personagens? (talvez você tenha, talvez cada unidade tenha uma história pessoal e isso seja importante para você)

• Você realmente precisa de ícones para a árvore tecnológica? (novamente, talvez você tenha idéias para inovar a interface do usuário para jogos RTS e esse é o seu ponto de venda).

Mas novamente; você deseja incluir apenas o que precisa - e deixar o que não for necessário para uma data posterior.

O princípio do MVP nem sempre funciona bem com um RTS, porque é a gestalt de todas as suas opções de design que o tornam divertido, mas há alguns pontos-chave que você pode apontar quando entender o que torna um RTS divertido.

As regras gerais básicas para tornar um RTS divertido são:

1- Viabilize o máximo de táticas possível. As táticas META devem exigir que você use vários tipos de unidades juntos.

Isso requer uma lista liberada de classes de unidades para você escolher com suas habilidades especiais finais para poder testar, mas você não precisa de cada tipo de unidade. Uma classe de unidade é uma unidade que desempenha um papel geral em seu exército e / ou possui uma habilidade especial. Se o seu plano é que cada facção tenha unidades semelhantes com skins diferentes e apenas estatísticas levemente modificadas, faça apenas uma facção. Se cada facção tiver vários níveis de algumas de suas unidades que são apenas versões melhoradas uma da outra, basta criar um nível dessa unidade. Se cada facção tiver um conjunto único de unidades, pode ser necessário construí-las. Apenas lembre-se de que deseja testar o maior número possível de classes desde o início, porque adicionar novas classes mais tarde pode atrapalhar completamente o equilíbrio do jogo.

2- Faça as táticas META mudarem conforme o jogo avança. Isso pode ser feito introduzindo novas unidades ao longo do tempo ou alterando as circunstâncias de suas batalhas.

Muito parecido com o nº 1, isso pode exigir uma lista de classes de unidades principalmente criada, mas é mais sobre como você testa seu MVP. Seu MVP deve poder restringir quais unidades estão à sua disposição, para garantir que os níveis iniciais ainda sejam divertidos sem todo o conteúdo do jogo final para liberá-lo.

3- Equilibre o tempo necessário para gerenciar sua base com a guerra. Um erro comum nos jogos RTS é pouca automação básica, o que significa que sua produção vai para o inferno se você precisar parar para controlar uma batalha.

Isso requer um sistema econômico totalmente liberado para ser testado. Um teste de MVP com 5 tipos de construção pode ter um bom desempenho, mas um produto final com 30 construções pode atrapalhar o jogador com tarefas econômicas e forçá-lo a revisitar a prancheta como gerencia / automatiza sua economia. A melhor opção aqui é criar todos os seus prédios que você planeja ter, para ter uma ideia de como é a base em escala real. Aqui, o melhor que você pode fazer é adiar gráficos sofisticados até que sua economia esteja finalizada.

4- Faça o ambiente afetar suas escolhas táticas.

É aqui que o teste do MVP oferece mais benefícios. A adição de fatores ambientais, como vantagens de alto nível, flanqueamento, armas especiais, moral das tropas, clima e vários níveis de paisagens abertas, tem o maior potencial de diferenciar seu jogo e torná-lo mais divertido ou estragar completamente a experiência porque você fez suas missões noturnas são tão sombrias que os jogadores ficam frustrados toda vez que precisam jogar uma. Você pode fazer esses testes bem antes de ter uma lista completa de unidades ou economia; então, esse seria meu primeiro objetivo de teste. Além disso, saber em quais ambientes suas unidades terão que lidar irá falar muito sobre como você precisa projetá-las e equilibrá-las. Isto'

Nem todo gênero é propício a um "produto minimamente viável". Ou, pelo menos, não da mesma maneira e eles não alcançarão o mesmo objetivo.

Considere um jogo de plataformas 2D baseado em nível. Um MVP para isso é principalmente sobre encontrar boas mecânicas de salto. Você não muda a física de salto do seu personagem depois de começar a criar níveis, por isso precisa acertar isso cedo. Então você escolhe um pouco de física de salto, constrói alguns níveis de teste e descobre que tipos de física são bons. Você também tenta algumas mecânicas, como atirar em alguns inimigos e descobrir como deseja que isso funcione, e / ou terrenos e habilidades especializadas (carregar itens, etc.).

O final desse processo é o que seria considerado o MVP.

Um RTS realmente não faz isso. Ou, pelo menos, ele nunca realmente pára . Todos os aspectos de um RTS se alimentam de outros aspectos. Embora seja verdade que há algumas coisas que você simplesmente não muda após um certo ponto no desenvolvimento, o desenvolvimento geral é muito mais fluido. Aqui está um exemplo.

No final do desenvolvimento do StarCraft I, a Blizzard fez o que eu consideraria uma mudança bastante impressionante. Nas construções anteriores, todo edifício Zerg que disponibilizava unidades produzia sua própria larva, que era usada apenas para produzir essas unidades. Basicamente, nessa construção, a larva era uma forma alternativa de enfileiramento de unidades. Isso foi transformado no mecânico que conhecemos hoje o Zerg: todas as unidades Zerg vêm de larvas produzidas em uma estrutura central.

Essa mudança fundamentalmente mudou a natureza dos Zergs como raça. Para outras raças, a troca de tecnologia (mudar sua unidade produtora de unidade primária) é um processo que requer um investimento substancial. Para os Zerg, você simplesmente derruba um edifício, e toda a sua infraestrutura de produção pode construí-los.

Mas isso contribuiu para a dinâmica dos Zerg em termos de design de unidades. Veja, os Zergs da SC1 foram basicamente construídos em torno de três unidades fundamentais: zerglings, hidraliscos e mutaliscos. Essa é a sua unidade básica e todo o resto é essencialmente uma unidade de suporte para elas. Então Zerg não muda de tecnologia como as outras raças; eles adicionam alguns X extras à sua composição militar existente. Os grandes interruptores tecnológicos para os Zerg eram principalmente sobre qual unidade fundamental o núcleo do seu exército é construído.

Cada elemento de design alimenta o outro. Se você alterar seu modelo de produção, precisará alterar o design da sua unidade para compensar.

Um "produto minimamente viável" para um RTS simplesmente não funciona em geral; toda a mecânica de um RTS interage de muitas maneiras para que um produto "mínimo" seja algo mais do que, essencialmente, um jogo completo.

Então, eu sugiro que você faça um RTS em pequena escala como seu MVP. Um RTS completo . Ele não precisa de todos os gráficos, mas precisa de todas as coisas que um RTS realmente possui. Isso poderá servir à função de um MVP: descobrir como fazer o jogo que você deseja criar.

Há várias respostas aqui adaptadas aos RTSs, mas eu queria destacar algo que é universal no conceito de Produto Minimamente Viável (MVP).

MVP é um conceito que existe há muito tempo, mas se tornou muito popular quando o desenvolvimento Agile entrou em cena. O conceito é bastante simples em sua essência: é o menor produto que é "bom o suficiente". É isso aí.

O que torna o MVP complicado é que ele é subjetivo e depende do contexto. Se você está trabalhando nos últimos marcos de um contrato militar, o MVP é nada menos que "o produto passa nos testes de qualificação". A qualificação do seu produto envolverá o teste de todos os requisitos estabelecidos para você no início do contrato (talvez anos atrás). Nada menos que isso se qualifica como MVP.

No início de um projeto, o MVP é uma barra muito mais baixa (graças a Deus!). No entanto, também é subjetivo. O que eu acho que é o produto mínimo como desenvolvedor é muito diferente do produto, e ainda é diferente do que o VP da minha empresa pode pensar. Você precisa escolher qual perspectiva do ator você está usando ao definir um MVP.

A voz mais crítica, na minha opinião, é a da pessoa que gerencia recursos finitos: seu tempo e seu dinheiro. Em uma corporação, esse pode ser um líder de projeto ou alguém em finanças. Pode ser um vice-presidente. Se você é uma pequena empresa independente, ou alguém que está escrevendo jogos solo, essa pessoa pode ser você . Mas não é o desenvolvedor de jogos normal que você . É você quem fecha as ferramentas de codificação e o software de arte e exibe o Excel para garantir que pode pagar as contas este mês. É você que tem que pesar o equilíbrio entre passar mais uma noite codificando seu pequeno projeto de paixão e sair com os amigos.

Como estamos falando de pequenos MVPs (é sobre isso que o vídeo que você vinculou), podemos começar a usar a abordagem do Agile para o conceito. Eu a frase assim:

O MVP para qualquer iteração / sprint / fase é o produto mínimo que justifica o gasto de recursos no tempo gasto na construção desse produto.

Essa definição é a razão pela qual a definição militar de MVP que usei anteriormente é válida: para eles, a única coisa que pode justificar os milhões gastos em um contrato militar é um produto de sucesso que faz tudo o que foi prometido. Mas para você, você pode estar justificando uma semana ou um mês. A barra é mais baixa.

Então, para isso, tire seu boné de desenvolvedor, vista seu terno e calça sob medida e vamos falar sobre o que acontece a seguir. Desenvolvedor que você termina de lançar um produto. O que você vai fazer com isso?

Mais tarde no processo, uma opção será enviá-lo - ganhar dinheiro com o lançamento do jogo. E, de fato, essa é uma definição-chave do MVP que nunca deve ser ignorada. Se um produto pode ser enviado, é um MVP candidato, porque ganhar dinheiro justifica muito recursos de desenvolvimento. Mas, no início, você não vai divulgá-lo. Portanto, o MVP é mais matizado:

No desenvolvimento inicial, o MVP é o produto mínimo que permite que você aprenda algo que vale o tempo necessário para produzi-lo.

Nota: isso pode não ser o que você pretendia aprender. Se o que você aprende é "este jogo nunca vai conseguir, então devemos sair agora ... mas, valeu a pena tentar", então você venceu. Você fez algum trabalho e achou que valeu a pena. Por outro lado, se você decidir fazer o jogo e pensar "caramba, nós perdemos quantos meses de nossas vidas?!?" então é uma forte sugestão de que você não estava fazendo um bom trabalho ao se limitar ao MVP. Se você estivesse se limitando ao MVP corretamente, as iterações anteriores já teriam sido consideradas como pagando por si mesmas - sem arrependimentos.

Então agora podemos chegar aos exemplos que outras pessoas escreveram aqui. Estas são respostas que exploram qual é o valor mínimo necessário para aprender alguma coisa. Mas todos eles perdem um detalhe abrangente: qual é o seu próximo passo?

O MVP depende do que você planeja fazer com esse MVP, uma vez criado. Tome a grande resposta de Philipp e o comentário de bxk21. A resposta de Philipp defendeu dois "minijogos", um de controle de unidades e outro de construção de bases. bxk21 argumentou que isso não é tão importante quanto o aspecto do gerenciamento de tempo. Então quem está certo?

Essa é uma pergunta complicada. Ambos estão certos, em certos ambientes. Presumivelmente, você está prestes a entregar o MVP lançado a alguns testadores para obter feedback. Que tipo de playtesters você planeja usar? Eles são profissionais do RTS? Se seus testadores de jogo não são especialistas em RTSs, a resposta de Philipp provavelmente está no local. Você está olhando para os pequenos pedaços de concreto do jogo. Eles terão antecedentes suficientes para poder comentar sobre esse tipo de coisa.

Agora, digamos que você de alguma forma obtenha testadores de jogo como TLO, Day [9] ou MVP. Estes são jogadores profissionais de RTS (ou no caso do Dia [9], pelo menos uma menção honrosa, pois não acredito que ele jogue profissionalmente). Se estes são seus playtesters, a opinião de bxk21 provavelmente é a correta. Eles não vão se importar com os pequenos detalhes sobre se você constrói edifícios ou se os próprios edifícios são construídos. Eles vão se importar com coisas sutis, como gerenciamento de tempo e balanceamento. Agora você não terá esse tipo de coisa pregada nos primeiros testes, mas deve poder deixar o sabor mostrar deles. Você deve se concentrar em criar um jogo que demonstre a sensação de que deseja retratar com um alto nível de habilidade.

Então, descubra qual você quer que seu próximo passo seja. O que você quer fazer com o seu produto? Em seguida, descubra qual é o seu MVP em relação a esse objetivo.

A palavra-chave em "Produto mínimo viável" é produto.

Um produto é algo pelo qual você cobra dinheiro com a expectativa de que alguém o compre. Se o que você deseja é um MVP, ele deve ser bom o suficiente para qualquer preço que você tenha em mente. Ou seja, pode ter um escopo limitado, mas deve estar completo suficiente para ser adequado à comercialização.

Acho que você provavelmente não quer um MVP, porque você está no ponto em que tem alguma idéia, mas nem sabe se vale a pena transformar em um produto. Parece que o que você deseja construir é uma demonstração ou outro protótipo. A maneira típica de fazer isso é fazer uma única fatia vertical do jogo que inclua toda a mecânica que você deseja testar. Em um RTS do tipo SC2, essa pode ser uma missão única (se você estiver executando um único jogador) ou um único mapa multiplayer.