Você realmente usa diagramas para modelar jogos? [fechadas]

Quero dizer principalmente UML, mas qualquer método que funcione é viável. Então - você realmente modela seus jogos com UML / outros diagramas ou métodos diferentes? Na minha universidade, eu tinha um assunto sobre modelagem com UML e parecia mais esforço do que benefício real, mas sei que isso pode ser apenas porque nunca criei um sistema de TI complexo e enorme. Então vale a pena e que tipos de diagramas / métodos são geralmente os melhores?

* Obviamente, muitas vezes é preciso escolher ferramentas concretas para problemas concretos, mas talvez haja alguns padrões.

Edit: esqueci uma coisa importante - você cria diagramas antes ou depois da implementação do material? O que quero dizer é - quando alguém projeta e implementa algo que geralmente muda de idéia ou surge algo inesperado e é necessário fazer alterações, às vezes importantes - e fazê-las em diagramas já complexos parece igualmente sem esperança, como no próprio código.

Eu gosto de pensar que tudo ao nosso redor pode ser representado, de uma maneira ou de outra, através de um diagrama. Mesmo que seja apenas um diagrama linear que representa a transição entre os estados de um objeto em particular ao longo do tempo (como um ser vivo, passando por vários estados, do nascimento à morte). Uso diagramas para apresentar meus pensamentos e idéias para a implementação real. Eu improviso bastante.

Portanto, meus diagramas estão na maioria das vezes em um nível muito alto e parecem mapas mentais .

Para citar alguns exemplos, este é realmente um mapa de herança de classe (um que foi cortado) no meu jogo em que Objeto Interativo é o tipo base.

Este é um FSM ( máquina de estado finito diagrama) para uma armadilha spikes (aquelas armadilhas impressionante em que você pisa e woosh picos de mostrar-se a partir do solo).

Este é um diagrama do manual (denominado dessa maneira porque se destina a ser um diagrama de retorno frequente ) que desenhei recentemente. Ele descreve os componentes de um jogo e também ajuda na coleta dos recursos necessários, pois você pode ver imediatamente o que é necessário e o que não é. Eu os recomendo em pequenos projetos, pois eles são enormes nos grandes. Eles podem ser ampliados ainda mais, para que possam consertar as coisas.

Quando eu vou para um nível mais baixo, geralmente é porque eu preciso planejar os aspectos mais complexos da minha arquitetura, e geralmente lido com a UML lá. Eu nunca me concentro em produzir UML absolutamente limpo e correto. Adotei o que mais gostei na convenção UML e a transformei em uma boa UML de mindmap-ish. É simples e faz o trabalho para mim, mas eu não aceitaria isso em um ambiente em que a UML real é esperada, por razões óbvias.

Outra situação em que tenho que ir para um nível mais baixo é quando tenho que descrever algoritmos reais. Eu uso o que chamo de diagramas de fluxo . É um formato inspirado nos diagramas usados ​​nos testes de caixa branca .

Uma amostra da armadilha de espigões que eu desenhei agora seria assim:

Normalmente, essa é a camada final entre diagramas e implementações reais de algoritmos. Se houver necessidade, detalho mais os diagramas de fluxo (com instruções extra executadas), deduzo ou estimo a complexidade e construo casos de teste precisos. Também prefiro diagramas do que pseudocódigo.

Não relacionado ao desenvolvimento de jogos, também tenho um bom formato para descrever as telas em um aplicativo com várias telas, a funcionalidade que o usuário pode acionar em cada tela e o relacionamento entre as telas. Normalmente, eu as construo antes de iniciar o desenvolvimento real e elas agem como um mapa durante todo o processo de desenvolvimento. Se for para um cliente, o diagrama da tela é ainda mais útil! Isso me ajuda a percorrer todo o projeto, do começo ao começo, e levar em consideração todas as funcionalidades necessárias. Portanto, é inestimável fornecer uma estimativa precisa de custo e tempo.

Então sim, eu definitivamente diagrama tudo e tudo. Se eu tiver uma idéia, eu posso e definitivamente vou desenhar um diagrama para ela. Se, de alguma forma, começo um projeto sem pelo menos um diagrama muito amplo para me apoiar, sinto-me aleijado.

Certamente eu faço - estrutural e comportamental - minha regra de ouro é que eu faço diagramas quando o custo de fazer o diagrama é menor do que tentar lembrar o que diabos eu estava pensando um mês depois - ou quando eu preciso me explicar claramente algum outro desenvolvedor

Diagramas de classes quando a hierarquia de herança se torna suficientemente complexa

Diagramas de objetos quando coisas como instanciação de objetos se tornam algo que limita a criação de um monstro de Frankenstein a partir de partes díspares - especialmente útil em usuários de vértices e shaders de pixel da pia da cozinha, para garantir que todos os bits necessários sejam empurrados pelo cano

Diagramas de sequência quando as interações detalhadas entre um conjunto de objetos se tornam complexas - isso é extremamente útil na modelagem de fluxos de renderização complexos, nos quais informações previamente calculadas são necessárias em locais a jusante pouco relacionados

Os diagramas são uma ótima maneira de se comunicar, documentar e auxiliar seu design , e o design é a parte mais significativa do desenvolvimento de software. A UML possui muitos recursos, mas você não deve usá-los todos ao mesmo tempo, apenas os que são úteis.

Ao navegar em uma nova cidade, você realmente para e olha para um mapa, em vez de apenas continuar e seguir as placas? É disso que trata o design versus a codificação. Quando as coisas não são familiares, quando o problema é complexo, quando você se sente perdido, é quando pensar em design é mais útil, e é melhor fazê-lo mais cedo ou mais tarde. É muito mais fácil alterar seu design antes de implementar qualquer coisa .

Os diagramas são uma ótima maneira de visualizar o problema e ajudar seu design, especialmente para os pensadores visuais (que é a maioria de nós no gamedev, eu imagino). Muitos problemas se tornam triviais, os defeitos se tornam óbvios quando são claramente mapeados em um diagrama. Alguns problemas que você pode encontrar em um diagrama:

• Muitas conexões com um único componente? Você pode ter um objeto deus difícil de manter
• Muitas interconexões? Talvez a modularidade possa ser melhorada, para tornar a arquitetura menos frágil
• Caminhos demais entre dois componentes? Talvez você tenha acoplamento apertado
• Para aplicativos de alto desempenho, como jogos, existem muitos componentes envolvidos no caminho ativo ou no loop interno? Isso pode afetar seu desempenho
• Na maioria das vezes, no entanto, o diagrama mostra inconsistências entre o design que você imaginou e a implementação real

Além disso, os diagramas são ótimos para comunicar e documentar seu design, seja para pessoas não técnicas ou pessoas novas no seu projeto - e lembre-se, em seis meses você também é praticamente novo no projeto!

Como você usa UML deve ser orientado a partir dessas considerações. Diagramação para o seu próprio bem? Use qualquer notação com a qual você se sinta mais confortável. Colaborando com outros desenvolvedores? Tente incluir os detalhes de chamadas à API, tipos de mensagens, instruções de dependências. Discutindo arquitetura? Caixas pretas e conexões simples serão suficientes. Ninguém usa o conjunto completo de recursos UML de qualquer maneira , além disso, é muito útil como um conjunto de notação padronizada que muitas pessoas entendem - enquanto meus rabiscos de guardanapo podem ser incompreensíveis para você e vice-versa.

Quanto a mim, uso diagramas o tempo todo - desenhos simples de blocos de notas para projetos pessoais, diagramas UML simples no trabalho. Esse diagrama UML é o que eu consideraria complexo demais, e que eu nunca faria porque o custo de produção e manutenção supera seus benefícios, mas é claro o YMMV.

Eu diria que existem dois tipos de diagramas. Diagramas formais e rabiscos.

Em relação aos diagramas formais, eu os faço quando trabalho com outros programadores, mas raramente faço quando estou programando sozinho.

No entanto, isso não significa que eu me sente e codifique o que vier à minha mente. Na minha opinião, a coisa mais importante na programação (ou na verdade qualquer coisa na vida) é pensar primeiro e depois .

A codificação é uma tarefa muito mecânica. Você digita e as palavras aparecem na tela. A idéia é que, quando você começar a codificar, você já deveria ter resolvido o problema em questão. Fazer rabiscos é uma ótima maneira de classificar seus pensamentos e até se forçar a pensar que você precisa fazer a parte de codificação corretamente. Os rabiscos não devem ser salvos para referência futura, apenas para que você possa entender facilmente seus processos de pensamento.

Não se preocupe se você demorar muito pensando. Eu acho que um bom equilíbrio acontece quando você dedica 90% do seu tempo pensando e 10% na codificação. Eu conheci vários programadores "seniores" que vivem de "não temos tempo para pensar, apenas para fazer". Mas mesmo se eles chamam seu código de "concluído" mais cedo do que aqueles que dedicam um tempo para pensar no que estão fazendo, eles (ou as almas infelizes que restam depois) passam inúmeras horas consertando e corrigindo algo que deveria ter sido construído corretamente do começo.

A melhor coisa é que o pensamento é grátis! você não precisa estar sentado no seu computador para pensar. Você pode pensar no código enquanto come, se desloca, se exercita ... De fato, as melhores idéias surgem quando você menos as espera; portanto, mantenha a mente aberta o tempo todo e comece a codificar apenas quando realmente souber o que quer. vamos codificar.

Aqui está um artigo relacionado com o qual eu concordo.

Editar : em relação ao formato e tipo de diagramas reais, eu recomendaria que você usasse estilo livre e realmente manuscrito em vez de usar ferramentas pré-empacotadas. Lembre-se de que o objetivo é ajudá-lo em seu processo de pensamento; sinta-se à vontade para desenhar o que quiser. A semântica é o que você quiser, e pode ser diferente entre diagramas e até entre partes diferentes do diagrama.

Existem três benefícios principais nos diagramas de estilo livre / manuscritos sobre as ferramentas pré-embaladas:

1. Você não é obrigado a respeitar o tipo de diagrama suportado por qualquer ferramenta que escolher. Às vezes, os mapminds funcionam, outras, algo mais como UML, mas outras, um diagrama lógico. Outras vezes, um diagrama completamente personalizado é o que funciona, e nenhuma ferramenta pode oferecer toda a flexibilidade dos diagramas de estilo livre (tente fazer um furo no papel e continuar no verso do papel, na sua embalagem favorita, e veja o que acontece)

2. Você gastará mais tempo realizando diagramação em vez de usar a ferramenta. Independentemente da ferramenta, caneta e papel são sempre mais rápidos na diagramação do que digitando e passando o mouse pelos menus para encontrar os elementos específicos que você está procurando.

3. Você não precisa de um computador para escrever à mão. Na maioria das vezes, faço projetos complexos, faço-os em uma biblioteca, um café ou mesmo dentro de um avião. Além disso, boas idéias sempre surgem no momento menos apropriado; portanto, sempre leve algo para escrever e algo para escrever.

Pode valer a pena destacar algumas palestras de diagrama de design da Game Developers Conference 2013. Estes são alguns exemplos muito práticos e testados na estrada - e parece que eles foram apresentados em muitas conferências ao longo dos anos.

(As outras respostas fizeram um trabalho admirável em demonstrar por que e como os diagramas focados no design podem ser tremendamente úteis no planejamento, construção, crescimento e manutenção de uma base de código, então deixarei esse aspecto em paz e confio que esses recursos possam ser úteis para quem visita a pergunta.)

Joris Dormans e Ernest Adams discutiram o sistema de design de jogo / diagrama de equilíbrio do Machinations . (Aqui está um vídeo do GDC Vault com parede paga da GDC EU 2012; exemplos da GDC 2013 no wiki de Dormans.) Em vez de tentar parafrasear, veja como o wiki descreve o sistema:

Machinations é uma estrutura teórica e uma representação gráfica dinâmica e interativa que descreve os jogos como sistemas dinâmicos e se concentra em ciclos de feedback fechados dentro deles. A intenção é encontrar uma maneira de expressar e investigar estruturas de jogo (recorrentes) metodologicamente. O Machinations oferece uma nova lente sobre a prática intuitiva e delicada do design e balanceamento de jogos.

Noah Falstein fez uma palestra chamada "A Arte Arcana dos Diagramas de Dependência de Quebra-Cabeças" (vídeo do GDC Vault com parede paga ). Não consigo encontrar nenhum link sem pagamento aqui, mas várias pessoas discutiram ou publicaram suas anotações on-line.

Ambas as conversas discutiram quando eles criaram e como eles mantiveram esses diagramas, em uma extensão ou outra.

Provavelmente, você deve verificar este artigo sobre como usar uma gramática abstrata simples para descrever seu ciclo de jogo, como ele pode ajudar a identificar problemas de design e como é fácil iterar nesse nível.

http://www.gamasutra.com/blogs/JoshuaStarner/20130205/186060/Applying_Abstract_Models_to_Game_Design.php

Também posso apontar para o meu próprio trabalho sobre o assunto, mais baseado na economia do ciclo de jogo, usando recursos abstratos para rastrear coisas como oportunidades, sorte ou preparação:

http://www.stephanebura.com/diagrams/

Se você acha que essa abordagem é útil, consulte o Machinations de Joris Dormans, uma ferramenta para criar esses diagramas e executar suas simulações:

http://www.jorisdormans.nl/machinations/

Todo o seu processo é explicado em seu livro:

http://www.amazon.com/Game-Mechanics-Advanced-Design-Voices/dp/0321820274/