Planejamento de jogos e design de software? Eu sinto que UML não é conveniente

Na minha universidade, eles sempre enfatizam e exaltam o design e outras coisas da UML, nas quais acho que não vai funcionar bem com o design da estrutura de jogos. Agora, eu só quero um conselho profissional sobre como devo começar meu design de jogo? A história é que eu tenho alguma habilidade em programação e fiz muitos jogos menores, como fazer com que alguns jogos de plataformas 2D funcionassem até certo ponto. Os problemas que encontro sobre o meu programa são o design de baixa qualidade. Depois de codificar por um tempo, as coisas começam a se deteriorar devido a um planejamento insuficiente (quando adiciono um novo recurso, isso me faz ter que recodificar todo o programa). No entanto, planejar tudo sem uma única falha de design é um pouco ideal demais. Portanto, algum conselho de como devo planejar meu jogo? Como devo colocá-lo em imagens visíveis, para que eu e meus amigos possamos visualizar os desenhos?

Eu planejava começar a codificar um jogo com meu amigo. Este será o meu primeiro trabalho em equipe, portanto, qualquer conselho profissional seria um prazer. Existem outras alternativas além da UML?

Outra pergunta é como a "prototipagem" normalmente se parece?

Eu só quero um conselho profissional sobre como devo começar o design do meu jogo?

O design do jogo é a especificação da jogabilidade, dos ativos, dos sistemas de pontuação etc. - estes não são específicos do software. Como tal, a UML é a ferramenta errada para essa tarefa.

Quando se trata de projetar o código para implementar esses sistemas, a UML é uma boa ferramenta para a tarefa, fornecendo à sua equipe o conhecimento e aderindo aos tipos de diagrama mais comuns. Normalmente, ao tentar criar um recurso, você saberá se precisa usar uma descrição ou um diagrama. Se você precisar usar um diagrama, a UML fornece uma maneira padrão de desenhá-lo, o que é uma coisa boa.

Depois de codificar por um tempo, as coisas começam a se deteriorar devido a um planejamento insuficiente (quando adiciono um novo recurso, isso me faz ter que recodificar todo o programa).

Isso geralmente é um problema com a maneira como você programa, e não com o que você planeja. Um bom software geralmente é fácil de estender e reutilizar. Se você seguir as boas práticas de programação, esse problema diminuirá. Mas um melhor planejamento também ajudará, e você não precisa de diagramas complexos para isso. Só ter uma lista de recursos significa que, quando você codifica uma coisa, você tem as outras características em mente e pode considerá-las enquanto codifica.

Portanto, algum conselho de como devo planejar meu jogo? Como devo colocá-lo em imagens visíveis, para que eu e meus amigos possamos visualizar os desenhos?

Parece que você está misturando 2 problemas aqui, o design do jogo e o design do código.

Sugiro primeiro escrever um design de jogo básico, especificando os recursos de que você precisa, os gráficos e sons de que precisa, como o jogo é vencido e perdido, etc. Procure 'documentos de design' se precisar de ajuda.

A partir daí, você terá uma idéia dos recursos que precisa codificar. Você pode examinar cada recurso por vez e tentar pensar em como implementá-los. Os diagramas podem ajudar a mostrar as relações entre diferentes classes e objetos em seu jogo, mas a habilidade de saber quais objetos precisam existir é algo que você precisa aprender através da prática e / ou leitura adicional.

Além disso, tente trabalhar em projetos menores e menos ambiciosos. Isso o acostumará a escrever código bom e funcional, sem a necessidade de planejamento ou reescrita extensos.

Não entender algo facilita a dispensa. A UML é uma ferramenta de engenharia usada para comunicar as idéias que você possui de maneira estruturada. Um jogo é um sistema que pode ser projetado como qualquer outro. De qualquer forma, a complexidade e o dinamismo de um jogo tornam uma representação visual de suas partes e de suas interações inestimáveis.

Os diagramas UML são visualizações diferentes de um modelo do sistema em discussão. Começo com casos de uso para uma pessoa sentada na frente do meu programa e iniciando-o. No caso de um jogo, existem dois tipos de usuários: designers e jogadores. Escrevo um caso de uso para cada uma das coisas que posso vê-los fazendo. Depois, faço alguns cartões CRC para descobrir quais serviços eu preciso fornecer. Depois, faço um diagrama de classes para as interfaces que fornecerão esses serviços e seus relacionamentos. Isso é baseado nos cartões CRC. A seguir, diagramas dinâmicos para eventos como inicialização, que exigem planejamento e orquestração. Em seguida, diagramas estáticos mais detalhados mostrando as classes que implementam as interfaces.

Enquanto isso, escrevo e prototipo e desenvolvo o código na direção de fornecer os serviços para dar suporte ao cumprimento dos requisitos do meu jogo. Nada é construído que não suporta o usuário através dos casos de uso. Escrevo alguns elementos inúteis do diagrama, mas entre a codificação da interface e a diagramação escrevo muito pouco código inútil. A diagramação me dá confiança de que entendo como a classe que estou escrevendo se encaixa em todo o sistema.

O que estou tentando enfatizar é que um programa trivial pode ser escrito sem planos, mas um jogo é tudo menos trivial. Algum tempo atrás, quando o OOP era novo, havia muita experimentação e algumas práticas recomendadas surgiram. A comunidade de desenvolvimento de software concordou que precisávamos de um idioma para escrever e analisar projetos de software. A UML é a linguagem que desenvolvemos. Todos nós o conhecemos e compreendemos; portanto, se você quiser usar as soluções de outras pessoas para seus problemas (livros, discussões on-line, artigos, catálogos de padrões etc.) e não reinventar a roda, precisará aprender a ler a notação padrão. Como bônus, quando você se força a pensar em seu sistema em outro idioma, aprende coisas inesperadas.

Existem muitas metodologias diferentes, mas todas identificam o problema e descrevem uma solução de maneira sistemática. Isso é engenharia. A UML é enorme e complexa, mas nenhum modelo usa todas as construções. É como um canivete suíço. Você precisa conhecê-lo e descobrir como usá-lo para apoiar seu processo de engenharia. O importante não é qual processo ou metodologia, mas você tem um. Caso contrário, você se afogará em complexidade.

Também estou trabalhando em alguns projetos de jogos independentes com um amigo (equipe para 2 pessoas). Como alguém em situação semelhante à sua, posso oferecer alguns petiscos que achei úteis.

1. Se suas idéias são difíceis, tente implementá-las uma de cada vez em projetos minúsculos de prototipagem. Por exemplo, estou fazendo um jogo de plataforma 2D agora, e acertar o salto do jogador é extremamente importante para mim. Então, eu fiz um novo projeto, onde as únicas duas coisas que acontecem são: a) desenhar o jogador na tela eb) detectar entradas e redesenhar o salto [o personagem não pode nem se mover para a esquerda ou para a direita]
2. Algumas pessoas podem desaprovar esse conselho, mas pense em escrever o manual do jogo primeiro (para explicar os conceitos, controles, objetivos). Isso pode fazer duas coisas para você - gerar um documento muito necessário, mas também descrever os subsistemas do seu jogo e todos os detalhes necessários para o jogador. Se você sabe com antecedência o que o jogador precisa saber, sabe com antecedência o que precisa fazer.
3. Escreva o código em pedaços pequenos o suficiente (também chamados de modularizados ) para que as peças fatoradas possam ser movimentadas ou melhor organizadas sem parecer que você está tentando remover todos os pedaços médios de espaguete de um prato de macarrão.

Espero que você tenha encontrado pelo menos uma informação útil e boa sorte!

Eu acho que existem algumas sugestões valiosas da UML que você não pode negar. por outro lado, lembre-se de que a UML foi criada para processos de negócios , você sabe, sistemas de modelagem que têm muitas pessoas interagindo com ela, todas com diferentes desejos, necessidades e desejos. A UML tenta garantir que você não deixe nada de fora ou fique impressionado com os detalhes.

UML é "uma maneira padrão de visualizar a arquitetura de um sistema"

UML descreve

• actividades
• atores
• processos de negócios
• esquemas de banco de dados
• componentes (lógicos)
• declarações da linguagem de programação
• componentes de software reutilizáveis

Mas se você está criando um jogo simples, precisa realmente modelar tudo isso?

• Atores: O jogador.

Quanto isso ajuda?

Modelar algumas das outras coisas, porém, é muito útil. Por exemplo, se você estiver criando um MMO pequeno, definitivamente deseja esquemas de banco de dados bem projetados.

Portanto, embora as orientações da UML sejam excelentes (saiba o que você está fazendo, anote os requisitos e esboce diagramas de fluxogramas sempre que necessário) e seus elementos sejam muito úteis, sinto que todo o processo da UML é um pequeno buraco quadrado para jogos.

UML não é uma coisa, é uma coleção de coisas que algumas delas valorizam outras nem tanto. os casos de uso de estilo mais antigo (pelo menos o que chamamos de casos de uso) que afirmam

• nome
• requisitos
• condições prévias
• gatilhos
• ações
• ações alternativas
• exceções

pode ser bastante útil. embora o que você encontre para "Casos de uso" se faça uma pesquisa na web (as imagens) seja mais para software geral.

Eu também daria algum crédito ao diagrama de Classes. isso mostra que você é capaz de mostrar o relacionamento entre todos os seus objetos e que conhece o layout da sua arquitetura.

O que se resume é que todo o seu conjunto de recursos deve ser planejado e bloqueado int (atendido em uma configuração de necessidade / necessidade) antes da modelagem e a diagramação é iniciada. tudo isso deve constar no seu resumo / tratamento / script (às vezes chamado de pitch, documento de recursos e história). a partir daí, você inventaria o material de documentos técnicos que tem seus modelos e diagramas.

existem empresas que usam UML, mas geralmente são empresas que possuem equipes de design e implementação separadas. as empresas que criarão toda a documentação e a entregarão a uma equipe de macacos de código para criar um protótipo / alfa. Dizem que, se você pode modelar seu jogo com precisão, deve poder entregá-lo a uma equipe completamente diferente e programá-lo, embora isso seja mais um sonho do que uma precisão.

Eles ensinarão você sobre a UML em sua universidade para ajudá-lo a comunicar suas idéias ao restante da equipe e mostrar aos professores que você tem um bom conhecimento prático dos princípios básicos de engenharia de software.

Como qualquer discussão sobre linguagem, ferramentas ou design - geralmente se resume a como você o usa. Escolha a melhor ferramenta / idioma / design para o trabalho e faça backup de sua escolha com uma forte justificativa. Admito que a UML não é tão flexível para a produção de jogos, embora eu possa dizer que a usamos efetivamente para modelar recursos de mecanismo como comunicação e tempo de rede, gerenciamento de tarefas paralelas e casos de uso. Não há nada pior do que explicar a mesma coisa para 5 membros da equipe, 10 vezes diferentes, porque eles não entendem direito. Aqui está a documentação, leia-a.

Dependendo de quão sólido você projeta e de como sua equipe é disciplinada, pode ser bastante produtivo poder modelar suas próprias construções em torno daquelas que ainda nem foram iniciadas ainda, e ainda saber exatamente como elas funcionarão devido ao documentação.

Apesar disso, você provavelmente ouvirá (e perceberá duramente) que esses são DOCUMENTOS VIVOS, e, a menos que sejam revisados ​​e atualizados regularmente, tornar-se-ão obsoletos com rapidez e eficácia.