Design iterativo em larga escala

8

Normalmente, no desenvolvimento de jogos, o desenvolvimento linear ( modelo em cascata ) é cheio de obstáculos que drenam a sanidade do programador (o jogo ficou horrível, não pode ser reprojetado). Digite o design iterativo . O design iterativo permite a criação de protótipos de várias possibilidades no espaço de jogo. Infelizmente, tem um problema maior . Assim que um projeto aumenta de tamanho, as iterações se tornam tediosamente longas, eliminando a principal vantagem: resultados rápidos.

Como reduzir as iterações de design para projetos de grande escala?

design-patterns development-speed

— newton1212
fonte

11

Lembro-me de ler este artigo sobre as estratégias que a empresa de Daniel Cook usou para aumentar sua taxa de sucesso nos jogos. Eles fizeram algo semelhante a um design iterativo, no qual um único programador ou equipe pequena prototipava uma série de conceitos de jogos - algo muito barato e rápido de fazer - antes de escolher quais agrupar recursos caros. O que você pode tirar dessa estratégia é que o fluxo de trabalho iterativo funcione, apenas para remover as peças que não funcionarão.

— JPtheK9

As iterações têm um tempo determinado, portanto sua duração é determinada pela frequência com que você pode obter feedback. As iterações não devem se tornar mais longas. Isso é cachoeira.

— Fuhrmanator

este é um tópico dos programadores stackexchange.

— precisa saber é o seguinte

4

Eu acho que uma boa infraestrutura pode ajudar isso. Um exemplo é ter um sistema de dados agradável e fácil de usar, pelo qual os engenheiros podem expor facilmente novos dados e os designers podem alterar rapidamente os dados e ver seus resultados. Outra boa é ter uma linguagem de script - como lua - que programadores de jogos e até designers podem usar para criar protótipos rapidamente.

Além disso, ter um bom pipeline de arte / ativos que seja fácil de usar e fácil de inserir ativos no jogo.

Basicamente, remova obstáculos para as pessoas que executam seus trabalhos e simplifique seus fluxos de trabalho.

Infelizmente, soluções prontas para essas coisas realmente não existem (mesmo em mecanismos de jogos populares, nem todos são problemas realmente resolvidos), o que significa que você precisará investir algum tempo de engenharia para obter essa agilidade. Então, infelizmente, a resposta é que você precisa gastar tempo para fazê-lo para poder trabalhar rapidamente, o que meio que derrota o objetivo. Depois de passar o tempo, as coisas vão bem. Se você puder reutilizar seu trabalho para projetos futuros, os dividendos serão ainda melhores.

— Alan Wolfe
fonte

+1. Portanto, não há vantagem no desenvolvimento de jogos, mas eles se tornam mais fáceis de combinar com a experiência. :)

— newton1212

2

Sim, embora eu tenha ouvido as pessoas argumentarem exatamente o oposto - cortem todos os cantos ao prototipar, apenas para fazer isso. Então, quando você terminar a criação de protótipos e tiver algo bom, jogue fora todo o seu trabalho e faça-o corretamente. É uma pergunta difícil, para responder (:

— Alan Wolfe

3

Timeboxing significa que as iterações não ficam mais longas

Você pergunta como diminuir as iterações. Mas isso implica que eles estão demorando mais, o que implica que você não está aplicando o boxe no tempo. Em qualquer iteração quando a complexidade começa a pesar mais (ou você tem outros contratempos imprevistos), não altera o comprimento da iteração. Em vez disso, você desce a adição incremental planejada no início da iteração. Alguns métodos iterativos sugerem fazer essa avaliação no meio de uma iteração (antes que seja tarde demais). Leia mais sobre o que o OpenUP sugere :

Gerenciar objetivos Quando uma equipe está ficando para trás significativamente, ou ocorrem problemas críticos que impedem a equipe de atingir os objetivos da iteração, pode ser necessário fazer um trabalho descendente para garantir que a equipe ofereça um incremento útil do produto até o final da iteração, maximizando valor das partes interessadas. Trabalhe com a equipe e as partes interessadas para revisar o Plano de Iteração e, conforme necessário, reduzir a ênfase em tarefas menos críticas, adiando-as para uma iteração subsequente. Em casos raros, se os objetivos da iteração ainda parecerem impossíveis de atingir, a equipe pode considerar encerrar a iteração ou reformular a iteração para um novo objetivo.

Se você observar o primeiro gráfico, poderá ver que o valor agregado é menor nas iterações posteriores. Isso significa que as iterações ainda demoram tanto quanto antes, mas talvez haja menos novas funcionalidades (relativamente) em cada iteração.

Como você diz, a força da iterativa é reduzir o risco, obtendo feedback com frequência. Parece que você está falando sobre a complexidade do projeto perseguindo você nas iterações posteriores? Não concordo que isso seja uma fraqueza da iterativa. É uma fraqueza da complexidade mal gerenciada.

Teoricamente, você coloca os maiores riscos no projeto com antecedência. Isso significa que você tem um projeto muito instável, mas como você gerencia os grandes riscos, ele deve se estabilizar. A complexidade, é claro, é um dos riscos.

Linguagens de script e processos automatizados ajudam a reduzir o risco de complexidade, que pode ser chamado de complexidade "acidental" (e é discutido em outra resposta). Projetos altamente iterativos, porém complexos (o Chromium é um bom exemplo, mesmo que não seja um jogo), possuem muita infraestrutura para gerenciar a complexidade. Dê uma olhada em https://www.chromium.org/developers para ver muitos exemplos de coisas como conselhos de codificação para o BuildBot .

Risco reduz ao longo do tempo O que esta figura não mostra é a estabilidade do projeto, que provavelmente se parece com isso:

Projeto se torna mais estável ao longo do tempo

Até que os riscos técnicos sejam bem compreendidos, você estará lidando com protótipos simples

— Fuhrmanator
fonte