Olá,
Eu nunca programei jogos (no nível gráfico), e queria saber:
Ao desenvolver um jogo, é feira uma análise semelhante ao desenvolvimento de um software qualquer, tipo comercial? Faz a especificação e documentação? E os diagramas UML, ajudam no desenvolvimento de jogos, e é possível utilizá-los para fazer uma boa análise dela (Caso de Uso, Classes, Sequencia).
Parece uma dúvida boba, mas gostaria de saber.
Grato
Sim, é semelhante.
Faz também. E, como na indústria de software comercial, cada vez mais práticas ágeis tem sido adotadas, com documentações menos pesadas.
Diagramas de estados ganham uma importância maior em jogos. O de classes também é bacana, mas como no caso de sistemas comerciais, costuma a ser caro demais manter esses diagramas.
O que os jogos tem de diferente é a fase de produção. Como o jogo é também uma aplicação artística, é necessário encontrar artistas, montar um storyboard, gravar músicas, etc. Existe uma etapa grande chamada “Game design”. Nela, define-se qual vai ser o jogo, as fases, os quebra-cabeças, enredo, linha gráfica, experiência de jogabilidade esperada, etc. Mesmo durante a programação, a equipe do game design faz testes de usabilidade, experiências tecnológicas, entre outras coisas.
Ela também gerencia a produção de conteúdo, necessária num jogo.
Só um pequeno exemplo:
Esses itens poderiam entrar como interação, ou seja caso de uso?:
Bem Lucas, na minha opinião, eu acho que você está equivocado quanto ao conceito de casos de uso. Reflita por um instante, feche os olhos e busque a resposta no fundo do seu coração: você acha realmente que é humanamente, tecnicamente e/ou financeiramente possível desenhar um diagrama de caso de uso para cada interação do usuário com o sistema ? Acho que a resposta é um tanto óbvia.
O que ocorre, é que casos de uso devem representar funcionalidades do sistema que adicionem valor de negócio para o usuário. Por exemplo, telas de cadastro geralmente não são documentadas como caso de uso. Especialmente quando se tem ferramentas que geram toda uma tela de cadastro bastando indicar o nome da tabela. Ou seja, compensa gastar tempo documentando algo que não levará nem metade desse tempo para ser implementada ?
Por outro lado, um processo de venda é um ótimo caso de uso, pois está relacionado com a obtenção de receita do seu cliente. Bons casos de uso necessariamente não precisam representar interações complexas entre usuário e sistema. Bons casos de uso permitem que você conheça melhor o sistema que você está lidando. Ainda nesse mesmo exemplo, quando você detalha o caso de uso e passa para sua análise você descobre que que há diversos sub-processos relacionados com a venda: você tem que registrar a movimentação financeira, baixar o estoque, calcular comissão para os seus vendedores, recolher impostos, etc.
Agora, voltando à realidade dos jogos. Eu por exemplo, não veria necessidade de elaborar casos de uso, por exemplo, para “usuário acessar menu de opções”. E por outro lado, não sei se o formato de casos de uso se adequa para descrever como o usuário interage com o jogo, pois é muito diferente dos sistemas comerciais. Em sistemas comerciais os documentos de requisitos servem para descrever uma realidade externa à equipe de desenvolvimento, que em geral, é alheia ao ramo de negócio do cliente (o que não é nada bom, nem desejável). Já no caso dos jogo, é um processo de criação, é a própria equipe de desenvolvimento que decide como o jogo vai ser. É claro que isso é pensado visando a aceitação dos jogadores, mas ainda assim a decisão está na equipe. Bem, eu nunca desenvolvi jogos, mas imagino que deva ser algo parecido com isso (bem a grosso modo): por exemplo, o pessoal do design cria um personagem, escreve seu enredo, o seu papel na trama, desenha sua forma, seus movimentos,poderes, etc. Depois, os programadores cuidam de implementar esse personagem. Nesse ponto, os programadores também usam de sua criatividade: como o usuário pode interagir ? que comandos devem ser executados para ele disparar aquela super-magia que acaba com todos os inimigos da tela ?
[quote=rmendes08]Bem Lucas, na minha opinião, eu acho que você está equivocado quanto ao conceito de casos de uso. Reflita por um instante, feche os olhos e busque a resposta no fundo do seu coração: você acha realmente que é humanamente, tecnicamente e/ou financeiramente possível desenhar um diagrama de caso de uso para cada interação do usuário com o sistema ? Acho que a resposta é um tanto óbvia.
O que ocorre, é que casos de uso devem representar funcionalidades do sistema que adicionem valor de negócio para o usuário. Por exemplo, telas de cadastro geralmente não são documentadas como caso de uso. Especialmente quando se tem ferramentas que geram toda uma tela de cadastro bastando indicar o nome da tabela. Ou seja, compensa gastar tempo documentando algo que não levará nem metade desse tempo para ser implementada ?
Por outro lado, um processo de venda é um ótimo caso de uso, pois está relacionado com a obtenção de receita do seu cliente. Bons casos de uso necessariamente não precisam representar interações complexas entre usuário e sistema. Bons casos de uso permitem que você conheça melhor o sistema que você está lidando. Ainda nesse mesmo exemplo, quando você detalha o caso de uso e passa para sua análise você descobre que que há diversos sub-processos relacionados com a venda: você tem que registrar a movimentação financeira, baixar o estoque, calcular comissão para os seus vendedores, recolher impostos, etc.
Agora, voltando à realidade dos jogos. Eu por exemplo, não veria necessidade de elaborar casos de uso, por exemplo, para “usuário acessar menu de opções”. E por outro lado, não sei se o formato de casos de uso se adequa para descrever como o usuário interage com o jogo, pois é muito diferente dos sistemas comerciais. Em sistemas comerciais os documentos de requisitos servem para descrever uma realidade externa à equipe de desenvolvimento, que em geral, é alheia ao ramo de negócio do cliente (o que não é nada bom, nem desejável). Já no caso dos jogo, é um processo de criação, é a própria equipe de desenvolvimento que decide como o jogo vai ser. É claro que isso é pensado visando a aceitação dos jogadores, mas ainda assim a decisão está na equipe. Bem, eu nunca desenvolvi jogos, mas imagino que deva ser algo parecido com isso (bem a grosso modo): por exemplo, o pessoal do design cria um personagem, escreve seu enredo, o seu papel na trama, desenha sua forma, seus movimentos,poderes, etc. Depois, os programadores cuidam de implementar esse personagem. Nesse ponto, os programadores também usam de sua criatividade: como o usuário pode interagir ? que comandos devem ser executados para ele disparar aquela super-magia que acaba com todos os inimigos da tela ? [/quote]
Obrigado pela resposta, concordo contigo.
É que na verdade não disse o motivo desse post. Sou professor, e vejo que os alunos tem muita dificuldade de assimilar conceitos e a prática de análise de sistemas.
Geralmente os professores passam os estudo de casos como: Caixa de Banco, Vendas, como voce disse, e Movimentações de Negócio que na verdade não estão no dominio de alunos. Isso mistura com conceitos de análise e engenharia e penso que dificulta o aprendizado.
A Idéia de analisar jogo foi justamente para facilitar a leitura do caso e fazer levantamnto de requisitos e as suas interações.
Um jogo de Mário por exemplo (Não pergunte que Mário :twisted: :twisted: ), é um jogo que penso que 80 % ou mais tiveram contato. Se eu passar a descrição do jogo, fica mais fácil dos alunos fazerem essa análise.
E depois que eles tiverem essa prática, puxaria para o lado comercial, o que o mercado exije.
Na verdade foi uma idéia minha para facilitar o aprendizado do aluno nos conceitos básicos, antes de entrar na realidade mercadológica.
Não sei se é uma boa idéia. Tem que colocar em prática.
Pode sim. Só que como o jogo todo roda num loop, assumimos apenas que os objetos tem “vida própria”, e realizam ações mais complexas do que os métodos que os compõe. Por exemplo, num jogo de Space Invaders, o caso de uso poderia ser igual ao do anexo.
Entretanto, note que estou assumindo implicitamente que a nave e o inimigo continuam se movendo. Que o tiro também se moverá. Que a pintura das naves é feita em algum momento, etc. Isso será feito em várias etapas do gameloop, e será cercado de etapas de pintura, calculos posicionais, etc, que não ficam representados no diagrama. Queremos mostrar é as interações importantes no decorrer do jogo, não tanto cada etapa desse ciclo.
Fazer isso deixaria todos os diagrama demasiadamente complexos desnecessariamente. Faltou também uma caixinha para o escore, que poderia ser atualizado logo após a explosão do inimigo.
No blog “Abrindo o jogo” tem um artigo muito bom explicando como criar um projeto de game, eu não tenho link aqui e não tenho acesso ao site, mas se não me engado o post chama “Trabalhar com jogos é sorte?”, alguma coisa assim, é um post de três partes e lá explica com bastante detalhes o processo de se criar um game. depois eu edito e coloco o link.
[]s
O link é esse aqui: http://blog.abrindoojogo.com.br/2009/09/03/trabalhar-com-jogos-e-uma-questao-de-sorte-parte-1-de-3/
Mas esse artigo explica a etapa de pré-produção, ou seja, de game design, que citei em cima. É como se fosse como montar um documento de requisitos bem detalhado, antes da UML e da análise do projeto efetivamente começar.
É mais relacionado ao conteúdo, e não ao software.
To imaginando aqui um analista de tetris escrevendo documentos de caso de uso.
[quote=ViniGodoy]O link é esse aqui: http://blog.abrindoojogo.com.br/2009/09/03/trabalhar-com-jogos-e-uma-questao-de-sorte-parte-1-de-3/
Mas esse artigo explica a etapa de pré-produção, ou seja, de game design, que citei em cima. É como se fosse como montar um documento de requisitos bem detalhado, antes da UML e da análise do projeto efetivamente começar.
É mais relacionado ao conteúdo, e não ao software.[/quote]
Realmente, mas de qualquer maneira acho q o artigo é relevante para o assunto, pelo menos para mim ajudou bastante a enteder alguns conceitos =D
[]s
