Posso usar a fluência dos recursos em meu proveito? [fechadas]

Posso usar a fluência dos recursos em meu proveito?

Toda vez que protótipo de um jogo, os recursos são adicionados inadvertidamente. Isso acontece por coincidência ou é fácil adicionar com base no conteúdo existente.

Se eu conheço o gênero do jogo, posso começar a fazer as mecânicas básicas e adicionar recursos à medida que se tornam aparentes?

Por exemplo, se eu quiser fazer um jogo de plataformas 2D ao longo de 6 meses, posso começar a correr, pular, disparar etc. e adicionar a mecânica do núcleo quando os encontrar inadvertidamente? Ou isso é muito arriscado para um investimento de tempo sem um plano predeterminado?

Minha lógica por trás disso é que o design será mais econômico. As opções de design serão construídas mais facilmente em torno do que é fácil de fazer (em termos de tempo).

Em resumo, há algo errado na criação de um jogo antes de eu projetá-lo?

Essa é uma pergunta interessante. Principalmente porque responder aumenta o dilema de tons de cinza versus preto-e-branco.

há algo errado na construção de um jogo antes de eu projetá-lo?

Se você pensa nessa pergunta como um tipo sim ou não, a resposta pode ser apenas: sim, existe. Se a resposta puder ser mais sutil, ela muda. Motivo: você nunca deve construir um jogo antes de algum projeto. Mas você com certeza pode salvar partes do design para mais tarde.

Isso significa que não acho que você deva ver o problema em questão como se faz ou não. Pelo contrário, é algo que você deve pensar em termos de graus. Característica que se arrasta talvez a segunda raiz de todo mal no que diz respeito ao desenvolvimento de jogos (a primeira, como Donald Knuth nos considera, é que "a otimização prematura é a raiz de todo mal" ). No entanto, na minha experiência, não pensar em nenhum dos principais recursos, ou seja, não ter pelo menos um design básico de onde você quer ir com sua mecânica básica, também não é uma boa idéia.

A primeira razão principal é que é útil em termos de recursos (incluindo o tempo como recurso) ter um planejamento para guiá-lo através - porque alcançar becos sem saída o tempo todo devido à tentativa e erro excessivos pode ser apenas um desperdício de tempo. recursos como tendo que incluir recursos imprevistos.

A segunda principal razão, em termos de design de jogos, é a coerência. Um bom design de jogo tem coerência conceitual ou consistência, se você quiser. Isso significa que o jogo em geral, a história, a implementação e até os gráficos devem se encaixar da maneira mais suave possível. É muito improvável que um design de jogo alcance algo assim se os principais recursos forem descobertos em movimento. Se não for por mais nada, porque em movimento há muita aleatoriedade: as coisas em que você pisará podem ter impactos muito diferentes, dependendo de quando no processo de desenvolvimento você as encontrou .

Não quero dizer que você não deva fazer o que disse. Estou apenas afirmando que você precisa encontrar algum equilíbrio.

Por exemplo, se eu quiser fazer um jogo de plataformas 2D ao longo de 6 meses, posso começar a correr, pular, disparar etc. e adicionar a mecânica do núcleo quando os encontrar inadvertidamente? Ou isso é muito arriscado para um investimento de tempo sem um plano predeterminado?

Começaria introduzindo uma ligeira modificação em sua frase. Ao correr, pular, disparar e etc, você já está implementando a mecânica principal. O que você adicionaria em movimento no seu exemplo são os recursos específicos do jogo.

Não é porque você sabe que o jogo será uma plataforma 2D, que correr, pular ou atirar não pode variar dependendo do design do jogo. Seu jogador pode correr nas paredes? O seu jogador pode flutuar no ar ao pular? Mesmo, seu jogador pode atirar enquanto corre? Seu jogador dispara apenas em uma direção linear ou através de uma parábola? Essas decisões podem depender muito dos recursos do jogo.

Mas entendo o seu ponto: essas mecânicas costumam ter algumas partes que variam muito pouco. Então, se você fizer algum jogo-design e decidir sobre recursos básicos, tanto quanto a ser um pouco certeza de como correr, saltar, tiro, etc vai funcionar, isso é um começo. Então você pode usar essas mecânicas e continuar construindo nelas.

É claro que você ainda pode encontrar mais tarde um novo recurso que exige que você altere essas mecânicas - não importa quão básicas elas sejam. Mas a chave aqui é a probabilidade. A probabilidade de que isso aconteça com muita frequência será menor se você ao menos pensar nas consequências de correr, disparar, pular e etc. para as idéias básicas que você teve para o jogo.

Por fim, se você quiser seguir esse caminho, sugiro o seguinte. Pense nisso como um processo iterativo. Você faz um pensamento inicial de design de nível amplo. Você implementa o que parece básico e mais "universal" dentro do seu jogo, para que ele tenha sucesso. Depois, você pensa um pouco mais sobre o design, reavalia o que implementou e implementa mais.

Ao fazer projetos complexos, como jogos, muitas vezes você não pode criar todos os recursos que deseja, porque está ficando sem tempo / dinheiro ou porque eles não foram tão bons quanto o esperado. Isso é conhecido como fluência de recurso. Mas há um outro lado disso; você também encontrará recursos que achava que não precisava, mas à medida que o projeto toma forma, sua necessidade se torna aparente.

É por isso que as pessoas criam protótipos - para aprender o que funciona e o que não funciona, para cortar recursos que não funcionam , mas também para encontrar novos recursos que seriam impressionantes . Se você não está fazendo nada daquilo que não está aprendendo , está fazendo errado.

Esse é basicamente o sentimento expresso em uma palestra chamada Prototipagem Avançada , de Chris Hecker e Chaim Gingold, que inclui muitos exemplos de seus trabalhos em Spore, onde eles eram frequentemente surpreendidos com o que funcionava e o que não funcionava, chegando a redesenhar todo sistemas baseados no feedback do protótipo.

Outro exemplo é o processo de design do Left 4 Dead ; No início, o jogo tinha apenas zumbis básicos, mas, ao testar com jogadores experientes, os designers descobriram que os jogadores se mantinham unidos de forma eficaz e o jogo era muito fácil, então eles adicionaram zumbis especiais para separar o time e manter o jogo emocionante.

Obviamente, isso não significa que você deve criar seu jogo sem nenhum design prévio . Você deve se certificar de que o núcleo do seu jogo seja divertido antes de prosseguir, porque essa é a parte mais difícil de fazer um jogo.

Eu diria que sim, vá em frente. Mas planeje alguns recursos / classes comuns com antecedência para ter alguma coesão entre cada novo componente.

O Unity é conhecido por sua abordagem componente ao desenvolvimento de jogos e permitiria essa forma de desenvolvimento facilmente. Se você não estiver usando o Unity, poderá replicar uma abordagem de semicomponente. Não estou familiarizado com outros mecanismos de jogos.

Todos os objetos do jogo Unity têm um componente de transformação. Isto indica a posição, rotação e escala do objeto. Portanto, faça uma classe 'transform' genérica para armazenar esses valores, além de uma referência ao objeto de jogo real, talvez.

Veja um componente 'Jump', por exemplo. Faça com que toda a lógica trabalhe com a classe de transformação de um objeto de jogo para manipular a posição. (Ou seu mecanismo já terá uma classe incorporada similar.) Você pode anexar essa classe 'Jump' a qualquer objeto, e a classe animará a posição de transformação quando uma ação for acionada (Jump.PerformJump () ou o que for). A classe Jump não precisa saber nada sobre seu proprietário (ou pelo menos informações mínimas).

Agora você pode se divertir criando vários componentes e anexando-os a objetos do jogo, combinando-os em um único objeto, etc. um componente genérico) etc.

Torne cada componente o mais genérico possível para permitir vários usos / variações. No FireWeapon, você pode especificar o sprite da bala, a velocidade, o dano, etc. Você pode tentar normalizar esses atributos, para que a velocidade e o dano sejam especificados entre 0 e 1. Em seguida, dimensione-os para os valores máximos do jogo. Dessa forma, você só se preocupa com diferenças relativas entre as armas. Além disso, isso se adapta às configurações globais, como dificuldade em que uma dificuldade mais alta causa um dano máximo mais alto etc.

Antes que você perceba, você tem um arsenal de componentes para conectar e agora pode desenvolver rapidamente para qualquer tipo de jogo.

Breve: na maioria das vezes você não pode ter uma única etapa de design seguida de uma única etapa de codificação. Você terá que alterná-los. Como regra geral, tente respeitar o que já foi projetado (não o que já está codificado).

Sobre não ter um design inicial (apenas um esboço ou uma imagem mental): se você não tem um design, você não tem um design. Você deve fazer algo para vir com um. Mas desde que você comece a construir um, tente respeitá-lo, não venha sempre com um novo.

Faça experimentações e obtenha recursos aleatórios pode ou não ser prejudicial. Pode até ser benéfico ou inevitável. Por exemplo: você sabe que deseja dar suporte ao salto (muitos RPG 3D / 2D não permitem saltar). Como você sabe? Porque você imaginou um mapa do jogo exigindo pular para classificar um obstáculo? Então o implementação salto é boa o suficiente, desde que permita ao jogador classificar esse obstáculo ou que ele tenha que cumprir determinadas características, como altitude máxima alcançável, seja ele impulsionado por itens ou objetos de jogo no mapa, a física deve incluir aceleração ou rejeição ( quando Mario pula em um inimigo, ele ganha impulso para elevar novamente e isso é muito importante para o jogo)?

Se você já pode responder a essas perguntas, seus documentos de design (imaginários ou reais) estão muito completos. Se você não puder responder, seu design está incompleto. Nesse caso, você precisará trabalhar novamente no design ou fazer experiências para preencher as lacunas. As oportunidades podem ser muito abertas ou muito restritivas. Se alguns dos seus níveis de jogo tiverem obstáculos, e você apenas precisar pular para eles, então haverá muita liberdade para decidir a altitude ou a velocidade máxima alcançável, talvez você decida fingir que existe um mecanismo de física para começar tudo apenas para melhore o visual da animação de salto, mas você não precisa disso para mais nada. (Em muitos jogos de RPG 2D, você não pode pular quando quiser, mas enquanto houver um único buraco no ladrilho no mapa, tentar entrar nele automaticamente dispara um salto no ladrilho ao lado do ladrilho)

Entendo que não há problema em codificar sem um design completo, desde que você respeite o que já foi decidido. Também pode ser inevitável em algumas situações, pois universos de jogos podem ser construídos a partir de uma variedade de processos de pensamento diferentes. Por exemplo, um jogo de cartas: eu sei que quero que as cartas tenham Ataque e Defesa, um certo número de cartas na mesa em um determinado momento e que o jogador durante o seu turno possa escolher com qual carta atacará qual outra carta. Pode parecer para alguns um projeto já completo, mas depois vem o equilíbrio do jogo, possível apenas através de muitas simulações. Depois de muitas simulações, decido que uma carta com o Ataque 10 é oprimida, posso simplesmente excluí-la do jogo, mas gosto demais e farei algo diferente, Vou criar uma nova regra que diz que, se um jogador atacar com uma carta, não poderá atacar com outra carta durante esse turno. Agora eu tenho uma nova regra que enriquece a mecânica do jogo, mas aplicá-la a uma única carta parece estranha (como um truque sujo), percebo que parece estranha e então decido criar um novo conjunto de cartas com números altos, mas o uma nova regra limitadora se aplica a eles. Agora eu tenho uma mecânica de jogo mais complexa, construída acima da original mais simples. Na minha opinião, virei a minha vantagem para fazer um jogo melhor.

Agora, uma coisa sobre esse último exemplo, no exemplo proposto do jogo de cartas, novas cartas podem resultar em novos ativos (aumento de custo, aumento de tempo). Mas acho que é um bom exemplo de deixar as oportunidades que você vê apenas quando a codificação influencia suas decisões de design de uma maneira boa.

Eu não acho que a maioria dos jogos que jogamos foram totalmente projetados antes da codificação, tenho certeza que eles tiveram que tomar decisões difíceis para cumprir os cronogramas e assim.

Quando alguém está pagando por tudo: explique, negocie.