quarta-feira, 19 de maio de 2010

Considerações sobre jogos

Tive uma matéria de Metodologia e nossa tarefa era fazer um anteprojeto.
Coloquei um trecho da base de pesquisa aqui e espero que ajude alguém.

Base de pesquisa:
A engenharia de software busca melhorar a qualidade do processo de desenvolvimento de software e do seu resultado [FLYNT 2005]. A qualidade do produto é medida a partir da confiabilidade, manutenibilidade e extensibilidade. O software confiável apresenta todas as funcionalidades especificadas pelo cliente e não apresenta erros. Software com facilidade de manutenção pode ser facilmente consertado nos mais variados erros. Um software extensível implica na liberdade de implementar novas funcionalidades para prolongar sua vida útil.

Para atingir tais objetivos, a engenharia de software se utiliza de práticas e metodologias (padrões de projetos) visando cobrir todos os pontos suscetíveis a erros, visto que software é uma tecnologia com pouca visibilidade. Ou seja, engenharia de software é um conjunto de conhecimentos que guiam os desenvolvedores.

A produção de jogos é uma área muito cara e demanda muito tempo [BETHKE 2003]. Isso ocorre pois jogos não são fáceis de trabalhar, precisam de uma mão de obra excelente e especializada para saber enfrentar um baixo recurso computacional (hardware) frente a gráficos pesados em tempo real e complexidade lógica (IA). Também precisa de vários recursos visuais, sonoros, de roteiro e ergonômicos, que demandam uma grande quantidade de mão-de-obra, e precisa gastar muito dinheiro com divulgação comercial para não acabar vendendo muito pouco. Resumindo, há uma grande necessidade de engenharia de software na produção de um jogo em escala comercial para que o projeto não seja abortado.

Além de todas estas características, um jogo precisa ser acima de tudo divertido [FEDEROFF 2002]. Mesmo que tenha toda uma qualidade de desenvolvimento e produção, nenhum indivíduo vai querer comprar um jogo que seja chato pois a principal característica deste é o entretenimento. Nos casos mais extremos alguns usuários chegam até a jogar em máquinas com baixo desempenho (interface lenta ou travando) afim de suprir esse desejo por diversão, porém descobrir como fazer um bom jogo é realmente difícil, existem uma série de características a serem consideradas.

Em primeiro lugar deve-se analisar o desenvolvimento geral. O jogo não pode ser nem muito fácil e nem muito difícil. Ao passo em que o jogo anda vai se ganhando cada vez mais experiência e surge a necessidade de apresentar uma melhor recompensa que a anterior com mais dificuldades motivando a continuação. A princípio, os primeiros níveis devem ser fáceis para ocorrer o costume com a interface e controladores e posteriormente a dificuldade deve ir aumentando em grau exponencial separando os bons jogadores e os regulares. Isso incentiva a competição, que é da natureza humana, e promove mais motivação.

Atrelado a isso deve existir uma interface visual adequada mostrando sistema de pontuação e níveis de dificuldade para servir como base de comparação na competição e gráficos atrativos, pois essa é a primeira impressão. Jogos com gráficos bem delineados e com bastante polígonos passam a ideia de bom desenvolvimento e lógica de jogo mesmo quando não é.

Outro fator importante é como se realiza a interação jogador-controlador considerando que este é o meio do usuário entrar no mundo do jogo e que existe uma grande lacuna entre eles [FEDEROFF, 2002]. O jogador deve-se sentir como se cada ação, cada “golpe” fosse ele mesmo quem estivesse fazendo, caso contrário o jogo não seria tão interessante e não ocorreria a imersão do jogador na fantasia.

A fantasia é o mundo englobado pelo jogo, é onde o roteiro principalmente entra. Uma boa história apresentando desafios como se fossem enormes e passando a ideia para o jogador de que ele é o responsável pelo rumo que tudo iria tomar no “mundo”, influência muito na vontade de jogar. Histórias triviais as vezes não são bem aceitas.

Mesmo assim, ainda existem segmentos de jogos que não seguem essa regra. Os puzzles por exemplo, são jogos com interface e jogabilidade simples porém exigem muito da coordenação motora ou inteligência do jogador.

As características acima foram usadas para criar uma heurística e uma forma de avaliação de jogos [DESURVIRE, 2004; FEDEROFF, 2002]. Apesar de existir algumas variações, os principais tópicos são: Gameplay, história, mecânica e usabilidade.

Este conjunto de heurísticas são importantes pois são base para a validação e qualidade do software além de guiar em algumas características da própria metodologia a ser desenvolvida no projeto. Seria uma forma de comparar as soluções encontradas na pesquisa e até decidir o que reutilizar quando não for criada uma boa solução.

Mesmo com tudo isso a área acadêmica ainda não dá a devida atenção para essa área promissora. De acordo com Sweedyk [2005] a primeira formalização de avaliação de jogos relevante (apesar de isolada) ocorreu em 1982, ou seja, ainda é uma tecnologia muito nova e precisa de muito estudo e aprofundamento.

Essa metodologia busca facilitar e padronizar o desenvolvimento de algo a partir de uma sequência de passos ou práticas efetivas. Para isso é necessário ter certo conhecimento nas áreas essenciais para produzir o objeto desejado. No mundo dos jogos, algumas das principais áreas voltadas para programação de software são: Game Design, Game Engine,Game Scripting e Level Design.

O Game Design é um dos documentos mais importantes pois é ele quem conterá toda a descrição do jogo, desde controlador até a história e ilustrações. Deve ser escrito de forma repetitiva e não ambígua visto que ele servirá para fazer o documento de requisitos de software e tirar dúvidas recorrentes. Para produzi-lo, precisa-se de bons roteiristas, jogadores, ergonomistas, grafistas e engenheiros de software.

Game Engine é a principal ferramente de produção de jogos, contém suporte a áudio, gráfico, controlador, IA, scripting e motor físico. Ela abstrai muitos algoritmos complexos tornando o desenvolvimento de jogos mais ágil. Algumas ferramentas dão a possibilidade de criar jogos precisando escrever poucas linhas de códigos.

Game Scripting é a forma de fazer jogos através de scripts. Essa etapa já abstrai muitas implementações, serve apenas para setar e organizar configurações, criar inteligência artificial e aplicar a história do jogo.

Level Design serve para fazer cada etapa do jogo, ou seja, criar os níveis e definir dificuldades de forma compreensível para o jogador com os elementos e ações disponíveis para o jogo. Normalmente é necessário muita criatividade e conhecimento em jogos pois cada nível deve aumentar a dificuldade gradualmente tornando o jogo nem fácil e nem difícil mesmo com a experiência adquirida pelo jogador a cada nível.

Além dessas áreas, jogos exigem muitos recursos computacionais em tempo real ao passo que precisa-se de algoritmos mais rápidos para que o jogo não tenha uma perda considerável de desempenho. Um jogo em que a resposta às ações demorem alguns segundos provavelmente não será jogado pois o usurário não conseguirá imergir na realidade dele. As ações não parecerão ser realizadas pelo jogador.

Referências:
FLYNT, John; SALEM, Omar. Software Engineering for Game Developers. Boston: Thomson Course Technology PTR, 2005.

BETHKE, Erik; ZESCHUK, Greg; MUZYKA, Ray. Game Development and Production. Texas: Wordware Publishing Inc, 2003.

FEDEROFF, Melissa; Heuristics and Usability Guidelines for the Creation and Evaluation of FUN in Video Games, Graduate School of Indiana University, Indiana, Estados Unidos, dezembro 2002. Disponível em: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.89.8294&rep=rep1&type=pdf. Acesso em: 11 novembro 2009.

DESURVIRE, Heather; CAPLAN, Martin; TOTH, Jozsef. Using Heuristics to Evaluate the Playability of Games, Vienna, Austria, Abril 2004. Disponível em: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.83.2695&rep=rep1&type=pdf. Acesso em: 11 novembro 2009.

SWEEDYK, Elizabeth; KELLER, Robert. Fun and Games: A New Software Engineering Course, Monte de Caparica, Portugal, Junho 2005. Disponível em: http://delivery.acm.org/10.1145/1070000/1067485/p138-sweedyk.pdf?key1=1067485&key2=2942597521&coll=GUIDE&dl=GUIDE&CFID=61042754&CFTOKEN=74891275. Acesso em: 11 novembro 2009.

Nenhum comentário:

Postar um comentário