Olá, estou à procura de informações sobre arquitetura de jogos. Padrões de projeto, cases, divisão de camadas, etc… Alguém possui maiores informações sobre isso?
Obrigado
[quote=UMC]Esse site aqui pode lhe ajudar:
http://www.pontov.com.br/site/
vlw
[/quote]
Tb aponto para esse http://www.pontov.com.br/site/
O primeiro passo é entender que o jogo não é simplesmente um software, mas um produto. E, como um produto, você terá que se preocupar não só com o programa, mas também com os dados que serão inseridos no programa.
É diferente de, por exemplo, criar um controle de estoque, onde você fornecerá os meios para se cadastrar produtos e registrar entradas, saídas e custos, mas não fará o cadastro dos itens de estoque em si.
Por isso, o jogo inicia-se na pré-produção, através de um documento chamado Game Design Document. Associado a ele, o time de artista monta concept art, history boards e outros elementos que ajudam o time a ter uma visão mais precisa sobre o que o jogo será. No game design document, também procura-se descrever como o jogador deve se sentir com o jogo, que tipo de interações ele terá que ter, e qual é a “velocidade do jogo” (será algo frenético, onde o jogador terá que ter pensamento rápido/instintivo, ou será mais lento, com puzzles mais elaborados?).
Outra característica é que o jogo é também um produto fechado e, diferente de muitos produtos do gênero, único também. Haverá no máximo expansões de conteúdo, mas dificilmente acréscimo de novas funcionalidades, ou versões futuras usando como base o código das versões iniciais. Uma vez pronto, ele é vendido, pago, e um novo desenvolvimento começa. Essa tendência tem mudado nos últimos anos, mas, em muitos jogos ela ainda se mantém.
A análise da arquitetura começa já com esses elementos em mãos. No fundo, eles nada mais são do que os requisitos mas, de qualquer forma, os requisitos ganham outra dimensão, já que parte da arquitetura será projetada única e exclusivamente para atende-los, sem preocupações de expansões ou flexibilidade futuras.
O que muda, em termos de modelagem, é que jogos são repletos de estados, por isso, o diagrama de estados ganha uma nova dimensão. Como o documento de game design é muito mais preciso que uma “conversa com o cliente”, também pode-se poupar muito esforço de documentação.
O jogo também roda num loop. Devido a isso, alguns diagramas, como o de sequencia, precisam ser simplificados para funcionarem direito. Caso contrário, haverá interações demais e muitas mais relacionadas a mecânica do a lógica.
As divisões de camadas dependem muito de que módulo do jogo você está olhando. Mas basicamente, os jogos são divididos na parte gráfica e sonora, física, IA e reprodução da narrativa. Cada módulo terá suas subcamadas. O módulo de física, por exemplo, é dividido em: camada matemática, camada de detecção de colisão, tratamento preciso de colisão e geometria, camada de física de corpos sólidos, camada de física de corpos rígidos e camada de ferramentas.
O processo de desenvolvimento de jogos era muito baseado ainda nos modelos waterfall, porém algumas desenvolvedoras como a LucasArts já anunciaram que trocaram com sucesso para o Scrum. Você pode ler mais sobre isso aqui.
Finalmente, muitos jogos são exclusivos de determinados hardwares. O que pode envolver ter gente especializada em linguagem de baixo nível e otimização. Isso permite a exploração de técnicas de sistemas de tempo real, como uso de profilers, benchmarks e processos mais matemáticos para a criação de algoritmos. Há relatórios e diagramas próprios para isso também, e você pode encontra-los em livros específicos sobre o assunto, uma vez que não existe uma técnica oficial como a UML.
Leia também:
Ponto V! - Funcionamento de um jogo
Ponto V! - Os softwares de um jogo
Pixelate - Undestanding Games
Olá pessoal, gostei muito dos links. O material é bom, mas é algo bastante prático. Estou procurando algo mais teórico. Vou passar algumas perguntas:
Já vi que o modelo MVC funciona bem em jogos, mas em jogos de um nivel mais complexo (nivel Xbox 360 =P) ele também se comporta bem? Existem outros modelos que competem com ele na área de jogos?
A divisão de camadas que vejo são Apresentação/Negocio(regras e fluxo do jogo)/Interpretação de comandos e controle geral (tanto o “loop” principal do jogo como a parte de interpretar os comandos vindos do usuário). Vcs sabem se a divisão feita profissionalmente é essa?
Procuro tb exemplos de usos de design patterns especificamente para jogos. Por exemplo em um jogo de tiro vejo que ao atirar com diferentes armas temos, no codigo, o padrão Strategy sendo executado para fazer com q cada arma tenha suas características de ação. Outro padrão que vejo que é interessante é Flyweight para trabalhar com cenario e State para fluxo principalmente relacionados ao controle do tempo no jogo. Possuem outras idéias de design patterns utilizados? Logico que posso dizer outros exemplos q me passaram pela cabeça e que sei que provavelmente podemos usar praticamente todos os DPs para jogos, apenas gostaria de exemplos de onde usar o que.
Obrigado!
[quote=ViniGodoy]O primeiro passo é entender que o jogo não é simplesmente um software, mas um produto. E, como um produto, você terá que se preocupar não só com o programa, mas também com os dados que serão inseridos no programa.
É diferente de, por exemplo, criar um controle de estoque, onde você fornecerá os meios para se cadastrar produtos e registrar entradas, saídas e custos, mas não fará o cadastro dos itens de estoque em si.
[/quote]
Em outras palavras, jogos não são apenas um processador de informação, ele tb devem simular um mundo modelado via software.
Tirando essa diferença, é como desenvolver qualquer outra peça de software.
Li uns artigos ali no ponto V. Achei interessante a separação entre engine e gameplay. Embora soubesse já das engines nunca tinha pensado na parte de desenvolvimento da engine e do jogo de modo tão separado. Tb o controle do tempo eh algo importante que eu não tinha nem imaginado.
Isso modifica um pouco a visão do MVC. Sendo assim tempo o View e o Control ficam no Engine. A parte de gameplay é o Model, podendo até mesmo ser feita em alguma linguagem de script ou outro tipo de dado dependendo sempre do jogo e da engine que desenvolvemos.
A divisão de camadas fica + como: Engine/Gameplay do que apresentação/negocio/interpretação de comandos. Sendo q cada um possui suas divisões, Engine por exemplo possui diversos sub-engines como sub-engine de som, sub-engine gráfica, sub-engine de interpretação de comandos do usuario, sub-engine de física, etc… mto interessante.
Se alguém tiver uma visão diferente ou quiser agregar algo ao q ja foi discutido pf fale! Este tópico é exatamente focado para fazermos essa discussão. Não quero respostas certas ou erradas, até pq isso n existe, cada caso é um caso e tudo que quero é ver novas perspectivas de desenvolvimento e arquitetura de software.
obrigado
Só vale lembrar que é uma peça de software de tempo real. E isso, por si só, já o torna muito mais complicado do que as “peças de software quaisquer” do mercado por aí.