F
ACULDADE DEE
NGENHARIA DAU
NIVERSIDADE DOP
ORTORealidade Virtual para Reabilitação
Neurocognitiva
Abel Dantas
Mestrado Integrado em Engenharia Informática e Computação Orientador: António Fernando Vasconcelos Cunha Castro Coelho (Doutor)
Co-orientadora: Artemisa Agostinha Monteiro da Rocha Dores (Doutora)
Realidade Virtual para Reabilitação Neurocognitiva
Abel Dantas
Mestrado Integrado em Engenharia Informática e Computação
Aprovado em provas públicas pelo júri:
Presidente: Nuno Honório Rodrigues Flores (Doutor) Vogal Externo: Leonel Morgado (Doutor)Orientador: António Fernando Vasconcelos Cunha Castro Coelho (Doutor)
Resumo
A inovação nas tecnologias de informação (TI) está a contribuir para uma abordagem personalizada e integrada na área da saúde. O aumento do rácio entre pacientes e terapeu-tas a partir do século XX e a emergência das TI pavimentou o caminho para uma relação profícua entre estas e a área da saúde.
No contexto da reabilitação neurocognitiva, a Realidade Virtual tem vindo a ser utili-zada no tratamento de pessoas com défice nas funções cognitivas, nomeadamente por via de Jogos Sérios. Tipicamente o paciente, fruto de Traumatismo Cranio-Encefálico (TCE) e/ou doenças neurológicas, sofre de défice cognitivo ao nível das funções executivas, vi-suoespaciais, da atenção e/ou da memória. A imersão do paciente num ambiente que emula a realidade pode reduzir custos e proporcionar um ambiente seguro para o treino de atividades de reabilitação que normalmente exigiriam a presença de um terapeuta ou pelo menos melhorar a diversidade de exercícios disponibilizados na sua presença.
No âmbito desta Dissertação foi desenvolvido um Jogo Sério em que o paciente é imerso num ambiente onde realiza atividades do quotidiano. A progressão é feita através de níveis de crescente dificuldade, onde o paciente realiza uma planificação de atividades que, de seguida, deve executar.
Este projeto decorre de outro previamente desenvolvido, um módulo Cidade Virtual onde o paciente planifica e realiza atividades do dia a dia numa cidade 3D com recurso a transportes públicos e onde é possível a re-configuração de parâmetros que direcionam a jogabilidade.
Os objetivos deste projeto são implementar o módulo Cidade Virtual, incorporar mé-todos de avaliação de desempenho do paciente e avaliar a usabilidade tanto ao nível dos periféricos como ao nível da interface gráfica. Espera-se que o protótipo desenvolvido constitua uma plataforma de Realidade Virtual para efeitos de reabilitação neurocogni-tiva.
Abstract
Innovation in Information Technologies (IT) is evolving to a personalized integrated approach on healthcare. The rise of patient / therapist ratio since the 20th century and the emergence of IT has paved the way for a fruitful relationship between these and health-care.
In the context of neurocognitive rehabilitation, Virtual Reality is being used to help people with impaired cognitive functions, namely through Serious Games. Commonly the patient, who has suffered Traumatic Brain Injury (TBI) or has some neurological disorder, has limited executive, visuospatial, attention or memory functions. The immersion of the patient in an environment that mimics reality can reduce costs and provide a safe setting for performing activities that would generally require the presence of a therapist or at least an higher diversity of exercises.
In the scope of this Dissertation a Serious Game was produced, where the patient is immersed in an environment where he can carry out activities of daily life. Progression is assured through levels of increasing difficulty, where the patient must first arrange and secondly perform a set of activities.
This project is based on a Virtual City module where the patient plans and undertakes daily activities in a 3D city, navigating the city recurring to public transportation. In this project it is possible to reconfigure the gameplay.
The objectives of this project is to implement the Virtual City, devise methods to assess the performance of the patient and evaluate the usability both to the level of peripherals and graphical interface. It is expected that the prototype will work as a Virtual Reality platform for neurocognitive rehabilitation.
Conteúdo
1 Introdução 1 1.1 Enquadramento e Motivação . . . 1 1.2 Descrição do Problema . . . 2 1.3 Objetivos . . . 3 1.4 Resultados Esperados . . . 3 1.5 Metodologia . . . 4 1.6 Estrutura do Documento . . . 4 2 Jogos 5 2.1 Indústria dos Videojogos . . . 52.2 Jogos Sérios . . . 5
2.3 Jogos Sérios na Reabilitação . . . 7
2.3.1 Abordagem Tradicional . . . 8
2.3.2 PESCO . . . 8
2.3.3 PREVIRNEC . . . 9
2.3.4 Virtual Life Skills . . . 10
2.3.5 Sumário . . . 11 3 Ferramentas 13 3.1 Motores de Jogo . . . 13 3.2 NeoAxis . . . 15 3.3 Unity . . . 16 3.4 Periféricos . . . 18 3.4.1 Dispositivos de entrada . . . 18 3.4.2 Dispositivos de saída . . . 20 3.5 Sumário . . . 22 4 Cidade Virtual 23 4.1 Conceitos . . . 23 4.2 Mecânica do Jogo . . . 24 4.3 Arquitetura . . . 26 4.3.1 Base de Dados . . . 26 4.4 Jogabilidade . . . 27 4.4.1 Picking . . . 27 4.4.2 Métricas de Performance . . . 27 4.4.3 Sistema de autocarros . . . 27
4.4.5 Modos de interface . . . 28 4.4.6 Iluminação . . . 28 4.4.7 Sons . . . 30 4.4.8 Monobehaviours e Gameobjects . . . 30 4.5 Sumário . . . 31 5 Interface Gráfica 33 5.1 Modos de interface . . . 34 5.1.1 Implementação . . . 34 5.2 Botões . . . 35 5.2.1 Implementação . . . 36 5.3 Menus . . . 36 5.3.1 Implementação . . . 37 5.4 Cursores . . . 37
5.4.1 Interação com os edifícios . . . 37
5.5 Fontes e Legibilidade . . . 38
5.6 Sumário . . . 39
6 Avaliação de Usabilidade 41 6.1 Controladores . . . 41
6.2 Interface Gráfica . . . 42
6.3 Perfil dos Participantes . . . 43
6.4 Testes . . . 44
6.4.1 Estrutura dos Níveis de Teste . . . 44
6.4.2 Dados a recolher . . . 44
6.4.3 Questionário . . . 45
6.5 Resultados . . . 45
6.5.1 Sumário . . . 46
7 Conclusão e Trabalho Futuro 47
Referências 49
A Anexos da Cidade Virtual 55
B Questionário SUS 59
Lista de Figuras
2.1 Pergunta de uma bateria de testes WAIS, a resposta é 1/3/6. . . 8
2.2 Sistema de configuração da PREVIRNEC, extraido de [TGF+98] . . . 9
2.3 Exercício onde o paciente deve regular a temperatura do fogão, extraído de [TGF+98] . . . 10
2.4 Módulos do Virtal Life Skills [Bro98] . . . 11
3.1 Arquitetura de um motor de jogo modular com networking, adaptado de [LJ02] . . . 13
3.2 Scene graphque representa parte do sistema solar, adaptado de [Hom] . . 14
3.3 Organização das entidades do protótipo desenvolvido numa estrutura de scene graph. . . 15
3.4 Joystickcom três graus de liberdade e com controlador de POV . . . 18
3.5 Movimentos num rato 3D, adaptado de [3Dc] . . . 20
3.6 Síntese de uma imagem estereoscópica num sistema de polarização de imagem . . . 21
4.1 Planta bidimensional da Cidade Virtual, cores representam lotes diferentes 24 4.2 Menu de planeamento relativo ao quarto nível, com limite temporal. . . . 25
4.3 Diagrama de pacotes . . . 26
4.4 Screenshot antes das otimizações de luminosidade. . . 29
4.5 Screenshot depois das otimizações de luminosidade. . . 29
4.6 Screenshot onde é visível o nevoeiro. . . 30
5.1 Botões relativos aos patamares. . . 35
5.2 Cursor de navegação, seleção e interação, respetivamente. . . 38
6.1 Diagrama das preferências dos participantes, azul representa a preferência do joystick enquanto vermelho representa a preferência do teclado e rato. . 45
A.1 Diagrama de Fluxo de atividades da Cidade Virtual, adaptado de [Mir12] 56 A.2 Arquitetura da Base de Dados, extraído de [Mir12] . . . 57
A.3 Arquitetura da Base de Dados - Autocarros, extraído de [Mir12] . . . 57
B.1 Questionário apresentado aos participantes. . . 60
C.1 Preferência de interface de acordo com a experiência de interação com computadores. . . 61
C.2 Preferência de interface de dois grupos etários de igual distribuição. . . . 62
C.4 Comparação dos valores médios das métricas de performance de acordo com a experiência de interação com computadores. . . 64
C.5 Comparação dos valores médios das métricas de performance em dois grupos etários de igual distribuição. . . 65
C.6 Comparação dos valores médios das métricas de performance por sexo. . 66
C.7 Comparação dos tempos médios de cada fase de acordo com a experiência de interação com computadores. . . 67
C.8 Comparação dos tempos médios de cada fase em dois grupos etários de igual distribuição. . . 68
Lista de Tabelas
2.1 Análise do Estado da Arte e comparação com o projeto foco desta Disser-tação . . . 12
Abreviaturas e Símbolos
AVD Atividades de Vida DiáriaLCA Lesão Cerebral Adquirida TCE Traumatismo Cranio-Encefálico IT Tecnologias da Informação AVE Acidentes Vasculares Encefálicos
WAIS Escala de Inteligência Wechsler para Adultos IDE Ambiente de Desenvolvimento Integrado API Interface de Programação de Aplicações WYSIWYG What You See Is What You Get
HDR High Dynamic Range
POV Point of View
LCS Liquid Crystal Shutter LCD Liquid Crystal Display
FOV Field of Vision, Campo de Visão
SDK Software Development Kit, Kit de Desenvolvimento de Software FPP First-Person Perspective, Perspetiva de Primeira Pessoa
GUI Graphical User Interface, Interface Gráfico de Utilizador
CSV Comma Separated Values
Capítulo 1
Introdução
1.1
Enquadramento e Motivação
Nos países industrializados verifica-se uma elevada incidência de lesões cerebrais [RBR05]. Estas podem ser fruto de uma doença congénita ou anomalia genética, caso contrário, se forem adquiridas após o nascimento denominam-se Lesões Cerebrais Ad-quiridas (LCA). Neste caso as causas são variadas, nomeadamente Traumatismos Cranio-Encefálicos (TCE) e Acidentes Vasculares Cranio-Encefálicos (AVE).
As LCA são uma das principais causas de morte ou incapacidade de desempenhar ta-refas essenciais para assegurar autonomia e independência nas atividades de vida diária (AVD) [DMC+12]. Os TCE ocorrem com especial frequência em jovens adultos, como consequência de acidentes de viação ou de trabalho. Independentemente da causa, estas lesões provocam frequentemente dificuldades em todas as áreas da vida e sequelas mui-tas vezes permanentes de ordem física, cognitiva, emocional, psicossocial e vocacional [SLPJ95,LHL04]. As sequelas de longa duração são de tal ordem que se verificam altas taxas de desemprego(40%-50%) e isolamento social (50%-60%) [HGVD00].
Devido aos avanços da tecnologia e das técnicas médicas, a mortalidade por via destas lesões diminuiu [SLPJ95], o que significa que frequentemente os pacientes são subme-tidos a um processo de reabilitação. A reabilitação neurocognitiva pretende avaliar e estimular os sujeitos com LCA de forma a melhorar a sua qualidade de vida e minimizar o impacto deste flagelo a nível social.
A avaliação neuropsicológica envolve a utilização de testes neuropsicológicos, como por exemplo, a Escala de Inteligência Wechsler para Adultos (WAIS), que é uma bateria de testes que afere a capacidade do paciente agir, pensar e de se relacionar eficazmente com o ambiente [Wec39]. No entanto, está documentado que o bom desempenho em
testes neuropsicológicos não implica um igual nível de funcionamento no que diz res-peito à execução de tarefas do quotidiano em contexto real, no que concerne às funções executivas [HW05].
Outro método baseia-se no acompanhamento do paciente num contexto real, no en-tanto, esta abordagem apresenta vários fatores limitativos, tal como o caso de a proficiên-cia física do paciente não o permitir, a necessidade de alocação exclusiva de um terapeuta para acompanhamento in loco e as ameaças do contexto real à integridade do paciente. Dada a natureza das limitações cognitivas, e por vezes também físicas, a adaptação dos exercícios ao perfil e à evolução do paciente é indispensável para evitar a sua desmotiva-ção, o que não é possível no formato "papel e lápis". De facto, a motivação do paciente é um elemento essencial para o desenrolar do processo de reabilitação e fator determinante no sucesso da integração social.
Deste modo, o contexto da reabilitação justifica a incorporação de métodos e ferra-mentas inovadoras para que o acompanhamento abranja uma maior parcela da população, se possível de uma forma mais personalizada, uma vez que se verifica uma elevada espe-cificidade nos problemas de cada paciente.
A evolução tecnológica testemunhada nas últimas décadas permite que hoje seja pos-sível aplicar Realidade Virtual ao campo da reabilitação [DCB+11b]. É possível desen-volver um ambiente onde o paciente é estimulado e avaliado sem os custos e riscos asso-ciados com as mesmas atividades no mundo real. Os pacientes podem ainda beneficiar com o facto dos ambientes puderem ser desenhados de acordo com as especificidades das suas patologias e evolução durante o processo de intervenção.
As tecnologias de informação têm assim o potencial de transformar continuamente a área da saúde. A indústria dos videojogos mostrou que é possível envolver pessoas na resolução de tarefas intelectualmente complexas de uma forma aprazível. Num Jogo Sério aplicam-se o mesmo tipo de ferramentas com finalidades além do entretenimento. [MOJ11]
Este projeto visa o apoio à reabilitação de pessoas com LCA, com recurso aos Jogos Sérios e à Realidade Virtual. Pretende-se a imersão do paciente num ambiente que emula a realidade, permitindo o acompanhamento de profissionais no decorrer de atividades do quotidiano. Foi desenvolvido, no decorrer desta Dissertação um protótipo com esta finalidade.
1.2
Descrição do Problema
O problema consiste no desenvolvimento de uma ferramenta que simultaneamente motive os pacientes para o processo de reabilitação, colmate a necessidade de feedback e adapte desafios de acordo com a situação clínica, perfil e evolução do paciente. Adicio-nalmente é importante que esta ferramenta tenha uma interface gráfica e física ajustada às
Introdução
necessidades dos pacientes e possibilite uma terapia remota (i.e., os pacientes realizam as suas sessões em casa, sendo os dados acessíveis aos terapeutas). Ao nível da implemen-tação, este projeto assenta sobre outro previamente desenvolvido: O projeto de mestrado “Jogo Sério para a Reabilitação Neurocognitiva: Cidade Virtual” [Mir12] neste foi desen-volvido, em Unity, um ambiente 3D relativo à cidade de Gaia e do Porto. Outro projeto desenvolvido neste âmbito foi um Supermercado Virtual [DCB+11a], implementado em Neoaxis, mas que nesta fase de desenvolvimento não foi integrado na Cidade Virtual.
1.3
Objetivos
O objetivo principal deste projeto é o desenvolvimento de um Jogo Sério (ambiente de realidade virtual) de apoio à reabilitação neurocognitiva.
Em termos de implementação tomou-se como base o projeto Cidade Virtual, sobre o qual se realizaram melhoramentos e otimizações, nomeadamente a inclusão de patamares (conjuntos de níveis, com requisitos semelhantes e grau de dificuldade crescente), me-lhor articulação do sistema de transportes ao nível da base de dados e meme-lhoramento da interface gráfica e física.
Procedeu-se ao desenvolvimento de métodos de avaliação de desempenho do utiliza-dor com base na sua prestação no Jogo Sério (i.e. estatísticas da prestação nos níveis, por exemplo, o quão rápido foi o jogador na execução do nível em relação ao mínimo tempo possível no patamar de “Horário de Funcionamento”). Com esta funcionalidade espera-se que a informação relativa ao desempenho venha a estar acessível ao terapeuta para que este tenha conhecimento da evolução do utilizador ao longo das várias sessões.
Outro desafio deste projeto é o estudo de periféricos que aumentem o grau de imersão do utilizador (por exemplo, monitores 3D) e que facilitem a interação com o jogo (por exemplo, ratos 3D, joystick), dado que muitas vezes os utilizadores poderão ter dificulda-des em utilizar os equipamentos tradicionais.
1.4
Resultados Esperados
Nesta Dissertação foi desenvolvido um protótipo de um jogo sério de apoio à rea-bilitação neurocognitiva adaptado à realidade portuguesa e segundo os objetivos acima identificados. Adicionalmente realizaram-se testes de usabilidade ao nível da interface gráfica e dos periféricos para validar o sistema desenvolvido.
Assim a nossa contribuição neste projeto será ao nível da construção de uma ferra-menta terapêutica que auferra-mentará a eficácia das práticas clínicas e a análise da usabilidade da solução desenvolvida, estabelecendo um conjunto de regras ou princípios para o de-senvolvimento de aplicações informáticas para este tipo de pacientes.
1.5
Metodologia
A metodologia adotada iniciou-se pela pesquisa do estado da arte, foram estudados os trabalhos relacionados para caracterizar o domínio do projeto e identificar falhas e défices a serem colmatados. Adicionalmente foram identificadas as tecnologias e ferramentas úteis ao contexto do desenvolvimento do projeto (parte significativa deste documento).
Numa segunda fase procedeu-se à fase de implementação, teste e avaliação do protó-tipo de uma forma iterativa e incremental. Os requisitos funcionais foram documentados em casos de uso que foram gradualmente validados no sistema. Por último, procedeu-se a testes e elaboração deste documento.
1.6
Estrutura do Documento
O presente documento está dividido em seis capítulos: Introdução, Jogos, Ferramen-tas, Cidade Virtual, Interface Gráfica, Avaliação de Usabilidade, Conclusão e Trabalho Futuro.
A Introdução contextualiza e define sumariamente o problema. O capítulo Jogos con-textualiza os Jogos Sérios no domínio da reabilitação neurocognitiva e apresenta alguns exemplos de trabalhos relacionados. No capítulo Ferramentas identificam-se e comparam-se as ferramentas mais adequadas ao decomparam-senvolvimento deste projeto. No capítulo Cidade Virtual, expõem-se sumariamente as características do protótipo. De seguida explora-se a Interface Gráfica e realiza-se a Avaliação de Usabilidade do sistema desenvolvido. Por fim temos a Conclusão e Trabalho Futuro.
Capítulo 2
Jogos
Um jogo é baseado num conjunto de regras onde é possível quantificar o esforço do jogador. Através de um conjunto de desafios, este fica emocionalmente afeiçoado ao resultado do seu esforço na tentativa de atingir a vitória. Os jogos apelam à esfera neuropsicológica, sociocognitiva e cultural, possivelmente devido à aptidão evolutiva do Homem para interagir competitivamente [Jul05].
2.1
Indústria dos Videojogos
“...specific kind of digital entertainment in which the gamer interacts with a digital interface and is faced with challenges of different kinds.”[ZW12]
A indústria dos videojogos catapultou o desenvolvimento de mais e melhores equipa-mentos e ferramentas, de tal forma que hoje estão disponíveis de forma generalizada e a preços acessíveis. Adicionalmente esta indústria tornou popular diversas tecnologias que hoje podem fácilmente ser aplicadas a Jogos Sérios. O sucesso da indústria dos vi-deojogos é inegável, em 2011 ultrapassou os 48 mil milhões de euros, ultrapassando a indústria do cinema [Reu11]. No entanto, não basta o avanço tecnológico, é necessário uma orientação cultural e económica que permita a difusão das novas tecnologias.
2.2
Jogos Sérios
Jogos Sérios são jogos cujo propósito se estende para lá do mero entretenimento. A utilização de Jogos pode ocorrer nas mais variadas áreas, por exemplo, treino militar, educação, saúde e formação empresarial [SJB07]. Uma das vantagens dos Jogos Sérios é ser possível reproduzir uma experiência sem o custo e limitações relacionadas com o mundo real (e.g., segurança, orçamento, tempo) [Cor06]. De acordo com um estudo de
mercado recente [Res10] o setor dos Jogos Sérios tem boas perspetivas de crescimento, assegurando atualmente lucros anuais que rondam os 1.5 mil milhões de euros, com um crescimento anual até 2015 de 47%.
Os Jogos Sérios podem contribuir para o desenvolvimento de diferentes tipos de ap-tidões, como as capacidades analíticas, espaciais, estratégicas, aumentar a perspicácia, memória, proficiência psicomotora, atenção visual seletiva, aliviar o stress e aumentar a motivação para a aprendizagem [MSS04]. Este último fator é devido à aprendizagem decorrer num contexto que é significativo para o jogador. O jogador está de tal forma envolvido emocionalmente com as circunstâncias do jogo que a aprendizagem é mais eficaz.
As vantagens da aplicação dos Jogos à formação e à área da saúde, documentadas por Enochsson et al. [EIT+04] foram aferidas através de uma experiência que relaciona a aptidão para videojogos com simulações de endoscopia em alunos de medicina. Os alu-nos mais experientes em jogos obtiveram melhores resultados, especialmente no que diz respeito à perceção tridimensional. Um estudo realizado por Hong e Liu [HL03] compara jogadores casuais com experientes e revela que os últimos têm maior tendência para re-solver problemas de forma analítica, enquanto os jogadores casuais são mais propensos a recorrer ao método de tentativa e erro.
Os Jogos Sérios para uso militar são tipicamente simulações de combate, operação de helicópteros, tanques, treino individual e em grupo. Um exemplo notável é o jogo Ame-rica’s Army, desenvolvido pelo Exército dos Estados Unidos da América, do tipo First Person Shooter (FPS), em que o jogador está imerso num ambiente altamente realista e deve coordenar-se com os outros elementos do seu esquadrão para levar a cabo missões de índole militar [Arm]. Nestes jogos os jogadores treinam a coordenação visuomotora e espacial, a capacidade de realizar várias tarefas simultaneamente (multitasking), compe-tências de trabalho em equipa com comunicação reduzida e proatividade [MC06].
No meio empresarial os Jogos Sérios são essencialmente para treino profissional. Po-dem ser muito específicos dependendo da atividade da empresa. Estas aplicações poPo-dem ajudar quando a atividade da empresa é complexa e dinâmica, como é o caso da aplica-ção Virtual Training Bank uma ferramenta de análise financeira e gestão de risco. Neste Jogo Sério os registos do banco virtual têm pistas de atividade fraudulenta, o jogador deve entrevistar o pessoal, examinar os registos e seguir o capital até à fonte [Gam].
Existem também aplicações de Jogos Sérios no domínio da educação, no entanto a sua utilização ainda não é generalizada, principalmente devido a atrito institucional, li-mitação de recursos (nem todas as escolas possuem computadores aptos para todos os alunos e professores se familiarizarem com os jogos) e falta de métodos para determinar a relevância de um jogo para a área de aprendizagem [SUFR06].
Finalmente quanto aos Jogos Sérios na área da saúde, estes estão a popularizar-se rapidamente, principalmente devido à vasta gama de aplicações [SJB07], nomeadamente:
Jogos
• Treino de profissionais de saúde, por exemplo, simuladores de cirurgia.
• Jogos que motivam o exercício físico. Várias consolas de nova geração possuem títulos e equipamentos direcionados para este tipo de atividade (e.g. Wii Fit [Ninb]). • Rastreio e diagnóstico de doenças do foro psicológico/psiquiátrico, por exemplo,
perturbação de stress pós traumático em veteranos de guerra.
• Educação orientada à saúde, por exemplo, aplicações que ensinam a ter melhores hábitos alimentares.
• Terapia de distração, por exemplo, ajudando doentes crónicos a alhearem-se de tra-tamentos desagradáveis.
• Reabilitação, tanto ao nível das funções motoras como cognitivas. Novas aplica-ções podem acompanhar sessões de terapia convencionais no sentido de acelerar o processo de recuperação.
2.3
Jogos Sérios na Reabilitação
A utilização de Jogos Sérios no contexto da reabilitação apresenta diversas vantagens. Por vezes a natureza da aplicação permite que o paciente possa continuar a terapia em casa; permite a configuração para melhor adequação à situação e perfil do paciente; ge-rir dinamicamente o tipo de desafios a propor ao paciente, maximizando o seu sucesso e motivação; disponibilizar informações pertinentes sobre o rendimento do paciente ao terapeuta [CPLC03].
As primeiras aplicações para apoio à reabilitação neurocognitiva foram adaptações de testes neuropsicológicos [DCG+09]. Mais tarde evoluíram para aplicações de Realidade Virtual, geralmente com motores gráficos 3D e periféricos adaptados às necessidades do utilizador, simulando a presença física deste num determinado Ambiente Virtual (AV). Estas aplicações são utilizadas no tratamento de um variado leque de perturbações do foro psicológico/psiquiátrico como por exemplo ansiedade, fobias, perturbações obsessivo-compulsivas, autismo, esquizofrenia e parkinson [Men10].
Quanto às funções executivas (envolvem planeamento, regulação e verificação de ações), que frequentemente ficam afetadas em pacientes com LCA, o contacto com um AV permite detetar défices de forma mais eficaz que os testes neuropsicológicos tradicio-nais e desenvolver intervenções de reabilitação.[SHR02]
Nesta secção são apresentados trabalhos relacionados com esta área, ou seja aplica-ções ou ferramentas atualmente utilizadas na reabilitação neurocognitiva.
Figura 2.1: Pergunta de uma bateria de testes WAIS, a resposta é 1/3/6.
2.3.1 Abordagem Tradicional
Apesar de não se tratar de um Jogo Sério, importa mencionar a abordagem tradicional, para que possamos traçar paralelos entre esta e a aplicação a desenvolver.
Uma das abordagens é o uso de testes neuropsicológicos, para avaliação do funcio-namento cognitivo, como é o caso da escala Wechsler Adult Intelligence Scale (WAIS), em que o paciente desempenha um conjunto de tarefas, responde a perguntas de cultura geral, problemas aritméticos, testes de vocabulário e ordenação e interpretação de figuras [Wec58]. A Figura2.1é um exemplo de uma pergunta de um teste WAIS.
2.3.2 PESCO
A PESCO (Plataforma de Estimulação Cognitiva) é um projeto desenvolvido por um grupo de investigadores da Universidade de Granada. A aplicação é constituída por um conjunto de exercícios que o paciente deve realizar em sessões de 40 minutos, num total de 12 sessões [Gua].
É feita uma avaliação antes e depois dos exercícios de estimulação. Os exercícios treinam as funções afetadas e são dinamicamente ajustados no decorrer das sessões. Trei-nam a memória de curto e longo prazo, de trabalho e visual, capacidades de planificação e atenção. A execução dos exercícios é realizada exclusivamente ao nível mental, sem recurso a nenhuma ajuda externa (e.g. anotação em papel). A aplicação funciona em ambiente Linux e é gratuita. Está em espanhol e preparada para interfaces táteis.
Jogos
Figura 2.2: Sistema de configuração da PREVIRNEC, extraido de [TGF+98]
Se compararmos esta plataforma com o sistema que se espera deste projeto, verifi-camos que não é um sistema distribuído (não permite terapia em casa), não tem uma componente imersiva e tem algum grau de adaptação à evolução do paciente.
2.3.3 PREVIRNEC
PREVIRNEC (Plataforma de Telereabilitação Neuropsicológica) é um sistema distri-buído de telereabilitação cognitiva open-source baseada em AVs [TGF+98], Figura 2.2. Este sistema é constituído por um conjunto de exercícios 2D e 3D que são altamente parametrizáveis por terapeutas, permitindo grande personalização e intensidade dos exer-cícios. Os pacientes podem realizar a reabilitação a partir de casa. De acordo com as métricas de performance o sistema reajusta a dificuldade dos exercícios.
A principal vantagem deste sistema em relação a outros é o seu grau de configuração, os neuropsicólogos podem alterar o sistema a muitos níveis. Os terapeutas acedem a uma aplicação web, desenvolvida em Java e com recurso a Ajax, onde podem aceder ao histó-rico dos pacientes, aos programas de reabilitação e aos seus resultados. Adicionalmente é possível definir os exercícios de reabilitação a serem executados e o respetivo intervalo
Figura 2.3: Exercício onde o paciente deve regular a temperatura do fogão, extraído de [TGF+98]
de tempo. A partir desta configuração inicial, o sistema reajustará a dificuldade de acordo com os resultados, sendo sempre possível o terapeuta intervir caso seja necessário. Os relatórios gerados pelo sistema sobre a performance do paciente são essenciais para que o terapeuta tome uma decisão correta relativa a reabilitação do paciente. Outra mais valia é a fácil adição de novas tarefas, devido à arquitetura modular da aplicação.
O AV consiste numa cozinha ( Figura 2.3 ) onde o paciente pode executar várias tarefas, apanhar comida, preparar pratos e pôr a mesa. O AV inclui estímulos sonoros para indicar eventos ao jogador, por exemplo, o telefone toca, indicando que é suposto ir atender o telefone. Os objetos são de quatro tipos diferentes: interativos (e.g. fogão), binários (e.g., interruptores), móveis (e.g., utensílios de cozinha) e transformáveis (e.g., um copo de água, que se pode encher mais ou menos).
Uma diferença essencial entre o PREVIRNEC e o sistema a desenvolver com base nesta Dissertação é o facto do primeiro ser baseado numa estrutura de tarefas, reduzindo significativamente a imersão, ou seja, não proporciona uma experiência contínua em 3D uma vez que tem tarefas também em 2D. As tarefas 3D consistem num AV onde os pa-cientes podem navegar e interagir com objetos. O objetivo é reproduzir atividades do quotidiano onde sejam utilizadas capacidades cognitivas como a atenção, memória, as funções executivas e a linguagem.
2.3.4 Virtual Life Skills
O projeto Virtual Life Skills é composto por um conjunto de AVs que o paciente pode explorar enquanto se depara com situações da vida quotidiana. O projeto é formado por
Jogos
(a) Módulo Supermercado (b) Módulo Café (c) Módulo Casa
Figura 2.4: Módulos do Virtal Life Skills [Bro98]
quatro AVs: Casa, Supermercado, Autocarro e Café [Bro98]. Nos vários AVs o paciente realiza tarefas procedimentais, que requerem interações numa ordem específica.
O Supermercado (Figura 2.4a) foi modelado com base num supermercado real na zona de Nottingham (Reino Unido). Neste módulo o paciente cria uma lista de compras, procura e seleciona produtos das prateleiras de acordo com a lista e paga o seu carrinho de compras. No Café (Figura2.4b) o paciente deve levar a cabo algumas tarefas simples, por exemplo, sentar-se numa mesa do café. O paciente tem de perceber a instrução “find a table” (comunicação), deslocar-se para a mesa (navegação) e selecionar a mesa para se sentar (interacção) [NCW00]. Finalmente no módulo Casa (Figura2.4c) o paciente deve: orientar-se na casa, movimentar-se com o joystick, ativar objetos na casa e perceber o que é suposto fazer mediante a tarefa proposta [CNR98].
Adicionalmente ainda há um módulo de transportes utilizado para articular os dife-rentes módulos, os autocarros são modelados de acordo com a realidade da cidade de Nottingham. A aplicação tem suporte para algumas interfaces físicas que facilitam a in-teração de pessoas com incapacidade.
O principal objetivo deste projeto é estimular a autonomia dos pacientes de uma forma motivadora. Este projeto não se adapta à evolução e perfil do utilizador e não é um sistema distribuído (não permitindo a terapia em casa).
2.3.5 Sumário
Neste capítulo introduziram-se os Jogos Sérios e o seu papel na reabilitação, assim como se estudaram diversos projetos desenvolvidos nesta área. De acordo com o que foi referido no capítulo anterior (Secção1.3) foi identificado um conjunto de características para o sistema a desenvolver: acesso ao histórico de performance do utilizador no sistema, ser imersivo, dinamicamente adaptável ao perfil e evolução do utilizador, integração com periféricos e adaptado à realidade portuguesa. A Tabela2.1 mostra a caracterização das aplicações discutidas neste capítulo segundo essas características.
Capítulo 3
Ferramentas
Este capítulo explora as diferentes ferramentas no âmbito dos problemas levantados no capítulo introdutório. São enquadrados os motores de jogo no contexto do desenvol-vimento de Jogos Sérios. De seguida são apresentados dois motores de jogo, o Unity utilizado na Cidade Virtual e o Neoaxis utilizado no Supermercado Virtual do projeto CARP-VR [DCB+11a]. Por fim, são analisados vários periféricos que podem ser úteis para aumentar a imersão e facilitar a interação com a aplicação a desenvolver.
3.1
Motores de Jogo
Figura 3.1: Arquitetura de um motor de jogo modular com networking, adaptado de [LJ02]
Um motor de jogo é um conjunto de módulos que apesar de não especificarem o comportamento de um jogo (lógica de jogo), nem o seu ambiente (informações sobre os níveis), contribuem para o funcionamento deste [LJ02]. Estes módulos podem ser responsáveis por um variado leque de funcionalidades: gestão de input, rendering 3D e
2D, motor de física, sons, inteligência artificial, deteção de colisões, gestão de memória, networking, streaming, threading, etc. Um motor de jogo é uma framework que aumenta a abstração do programador, permitindo que este se dedique mais aos aspetos específicos do jogo que está a implementar.
Na Figura3.1está representada a arquitetura de um jogo desenvolvido num motor de jogo com uma componente distribuída.
Redesenhar componentes para um jogo não é nem necessário nem eficiente em termos de custos. No entanto, os motores de jogo estão geralmente direcionados para um certo tipo de jogabilidade, i.e., um motor de jogo para um simulador de voo pode não ser útil no desenvolvimento de um Shooter (jogo de tiro) [BEW+98].
Há motores de jogo com diversos níveis de abstração, alguns apenas disponibilizam funcionalidades de rendering 3D, neste caso o programador deve implementar os módulos em falta. Estes motores de jogo denominam-se motores gráficos ou motores de rendering. Tipicamente os motores de jogo e os motores gráficos disponibilizam um scene graph, ou grafo de cena, uma estrutura de dados que permite a representação, organização e acesso dos objetos do AV.
Figura 3.2: Scene graph que representa parte do sistema solar, adaptado de [Hom]
A Figura3.2mostra um scene graph de um AV 3D, neste caso representando parte do sistema solar. Contém a Terra e Marte em orbita do Sol, e a Lua em orbita da Terra. Há nós do grafo que representam os pontos pivô dos planetas (a vermelho). Os modelos dos planetas (a verde) são nós filhos dos seus pivôs espaciais, estes modelos ficam centrados na posição do seu pivô. A rotação do pivô do Sol causa a movimentação dos planetas, o mesmo acontece com a Terra e a Lua. Os scene graphs são um artefacto básico ao nível
Ferramentas
da computação gráfica, mas nem sempre utilizados em todos os motores de jogo. O motor de jogo utilizado no desenvolvimento do protótipo, o Unity faz uso desta lógica extensi-vamente. No painel Hierarchy visível na Figura3.3são visíveis alguns dos elementos do scene graphdo protótipo desenvolvido.
Figura 3.3: Organização das entidades do protótipo desenvolvido numa estrutura de scene graph.
3.2
NeoAxis
Neoaxisé um motor de jogo 3D com ambiente de desenvolvimento integrado, baseado no motor gráfico Ogre [Ogr] para o desenvolvimento de jogos, simulações, Jogos Sérios e sistemas de realidade virtual [Eng]. Este foi o motor de jogo utilizado no desenvolvimento do módulo Supermercado Virtual no projeto CARP-VR [DCB+11a].
Vários jogos sérios foram desenvolvidos em Neoaxis. Um exemplo é um programa de simulação da Yamaha para motociclistas, onde com recurso a 5 projetores à volta de
uma mota é criado um AV dinâmico onde o rendering reage à velocidade da mota [Aca]. Outro exemplo é um software para treino de profissionais de saúde para lidar com pessoas com limitações físicas, Emergency Medical Services for the disabled Virtual Environment (EMSAVE) onde o jogador lida com situações de emergência envolvendo pessoas com deficiências [oUSC]. O jogo decorre num AV Open World, isto é, num ambiente 3D onde o jogador pode explorar o cenário livremente.
Do ponto de vista técnico o Neoaxis permite o desenvolvimento de jogos para Mi-crosoft Windows e Apple Mac OS X. O programador tem à sua disposição um conjunto de ferramentas (Toolset) integrado num IDE (Ambiente de Desenvolvimento Integrado), com um editor WYSIWYG (What you see is what you get), permitindo a manipulação do software por meios visuais. A programação é feita com base numa API (Interface de Pro-gramação de Aplicações) .NET, e a linguagem de proPro-gramação é C# apesar de ser possível a utilização de C e C++. O Neoaxis tem suporte para desenvolvimento de aplicações em janela, sendo as bibliotecas WinForms[Mon] e WPF [Win] suportadas.
Adicionalmente o Neoaxis possui um módulo de inteligência artificial que permite es-pecificar comportamentos de agentes, assim como um sistema de pathfinding (procura de percurso). Possui também um módulo de sincronização de objetos de jogo na rede e uma variada gama de classes tipicamente utilizadas no desenvolvimento de jogos, por exem-plo, manipulação de superfícies líquidas, gestor de fações, portas, interruptores, câmaras, entre muitas outras funcionalidades.
O motor gráfico do Neoaxis baseado em Ogre, com suporte para OpenGL e DirectX 11, permite High Dynamic Range (HDR) rendering a 64 bit com efeitos de brilho, adapta-ção da exposiadapta-ção e mapeamento de tons, possui também efeitos pós-processamento (e.g. Profundidade de Campo (DoF) e Luminosidade Volumétrica (God Rays), suporte para vários tipos de animação, um sistema de partículas e inúmeras funcionalidades de lumi-nosidade e sombras. Quanto ao motor de física, este assenta sobre o PhysX Engine[NVIb] da NVIDIA. A nível de GUI (Interface Gráfico de Utilizador) existe um sistema de inter-face expansível optimizado com um editor que permite a criação de menus, diálogos, janelas, HUD (heads-up display) e GUIs 3D. O Neoaxis está também preparado para uma variada gama de periféricos, nomeadamente Kinect [XBo] e Joysticks, permitindo ainda por via de uma framework a configuração de periféricos não convencionais.
Vale a pena referir que o Neoaxis é gratuito apenas para fins não comerciais.
3.3
Unity
Unityé um motor de jogo e ambiente de desenvolvimento, da autoria da Unity Tech-nologies, para a produção de jogos para Web, Desktops, consolas e dispositivos móveis [Tecb]. Este foi o motor de jogo utilizado no desenvolvimento da Cidade Virtual.
Ferramentas
As ferramentas de edição do Unity, à semelhança das do Neoaxis, operam segundo uma lógica WYSIWYG, com diferentes vistas configuráveis para manipulação do AV. Uma das principais vantagens do Unity é a abordagem à gestão de recursos de jogo (Assets). Estes podem ser modelos 3D, texturas, materiais, sons, scripts, etc. Estão disponíveis através de um sistema de gestão, onde é possível organizar, pesquisar e partilhar assets com o resto da equipa de desenvolvimento.
O Unity presta ainda um serviço através do editor que permite a comercialização e aquisição de assets, a Asset Store. Este serviço vai no sentido de uma democratização do desenvolvimento de jogos, uma vez que ajuda à articulação dos vários intervenientes no processo. É possível, por exemplo, um ilustrador disponibilizar texturas que serão utilizadas por um programador no seu jogo indie (jogo desenvolvido por uma pessoa ou por um grupo pequeno de pessoas sem apoio financeiro). Como na Asset Store estão disponíveis modelos 3D e outros recursos de qualidade gratuitamente, foi possível utilizá-la no decorrer deste projeto. Outras vantagens do Unity é o grande número de plug-ins desenvolvidos pela comunidade, como é o exemplo do CityEngine [Zur], um software de modelação 3D para a geração de ambientes urbanos, utilizado na Cidade Virtual.
Graficamente o Unity suporta OpenGL e DirectX 11, permite rendering HDR e ou-tros efeitos, assim como extensiva configuração do rendering através de uma interface de baixo nível para as funções base de desenho. Possui também mais de 100 shaders (módulos de software para fazer o ajuste de luz e efeitos visuais). No que diz respeito às luzes, uma das funcionalidades mais interessantes é uma ferramenta de lightmapping que transforma luzes estáticas em texturas para melhor performance. Há também outras funcionalidades de luz como dual lightmapping, sombras em tempo real e UV Unwrap-ping automático. Quanto aos efeitos especiais, há uma vasta gama de efeitos de pós-processamento, manipulação de líquidos, efeitos de render para texturas (útil para por exemplo ver o reflexo num espelho) e criação e manipulação de partículas. O motor de física, à semelhança do Neoaxis é o PhysX Engine da NVIDIA.
Com recurso à biblioteca FMOD [Teca], o Unity permite a manipulação de áudio, através de aplicação de filtros ou alteração de tom, distorção, reverberação e eco. O áudio pode mudar dinamicamente de acordo com a distância do ouvinte à fonte do som ou pode ser dinamicamente configurado através de scripts.
Há também ferramentas para a edição de terreno, que é tridimensional de perto mas mapeado como uma textura quando ao longe. Pincéis para aplicação de arbustos ou relva e uma ferramenta de criação de árvores são apenas algumas das funcionalidades. O módulo de inteligência artificial permite pathfinding (procura de caminhos), adicionalmente, a nova versão (Unity 4) possui métodos que permitem que os agentes reajam a ambientes dinâmicos.
Quanto à programação, pode ser feita em UnityScript (uma linguagem especifica do Unity com uma sintaxe semelhante a Javascript), C# ou Boo (sintaxe semelhante a
Python).
A versão gratuita do Unity não permite desenvolvimento de software por empresas com um volume de negócios anual superior a 75.000e, nem o desenvolvimento para plataformas móveis.
3.4
Periféricos
Devido às limitações físicas frequentes nas pessoas que sofrem de LCA as ferramentas de interação convencionais (rato e teclado) podem não ser as mais eficazes. Adicional-mente por via de novos dispositivos de saída pode-se aumentar o grau de imersão no AV. Nesta secção exploram-se diferentes dispositivos de entrada e saída, no sentido de aferir quais os mais adequados para a interação necessária no âmbito deste projeto.
3.4.1 Dispositivos de entrada
Um dispositivo de entrada é um periférico que disponibiliza informação sobre a in-teração do utilizador a um sistema informático. Os dispositivos podem ser classificados segundo o tipo de interação (mecânica, visual, áudio, etc) e pelos graus de liberdade que proporcionam. Um rato tradicional possui dois graus de liberdade, o utilizador manipula as coordenadas x e y do cursor.
3.4.1.1 Joystick
Figura 3.4: Joystick com três graus de liberdade e com controlador de POV
O Joystick foi inicialmente inventado por um oficial da marinha dos Estados Unidos da América para pilotagem remota de aeronaves não tripuladas [Lab11]. Há uma variada
Ferramentas
gama de joysticks com diversas características técnicas. No âmbito desta Dissertação são de interesse os joysticks com pelo menos três graus de liberdade como o representado na Figura3.4. O joystick representado também possui um controlador de POV (Point of View), um sensor analógico que permite o controlo de mais dois graus (indicado com o 2 na Figura3.4).
Comparativamente a um rato convencional, o joystick proporciona uma interação mais simples uma vez que pode ser operado por pessoas com pouca destreza manual, possui mais graus de liberdade aumentando a imersão, é suportado pelos motores de jogo em questão e é de fácil aquisição e baixo custo.
3.4.1.2 Controladores Convencionalmente Utilizados em Consolas
Estes dispositivos são tipicamente sensores de movimentos, que permitem uma vari-ada gama de interações com o software e promovem uma dinâmica imersiva. São muito populares nas consolas da atualidade, PlayStation Move [Ame] da PlayStation 3, Wii Re-mote[Nina] da Nintendo Wii e Kinect [Mic] da Xbox 360.
As diferenças entre estes dispositivos são: o Wii Remote é o dispositivo mais simples e fácil de utilizar com muitos acessórios; o PlayStation Move tem uma bateria recarregável e é muito preciso; o Kinect não requere controlador uma vez que funciona unicamente com uma câmara que deteta os movimentos do jogador sem ser necessário o recurso ao toque, deteta também caras através de um software de reconhecimento facial.
As vantagens destes interfaces são a facilidade de aprendizagem, devido à proximi-dade à interação na realiproximi-dade, a velociproximi-dade adquirida na interação e o grau de imersão proporcionado [Zha98]. No entanto, se utilizados da forma convencional, apresentam uma série de problemas que impossibilitam a aplicação na área da reabilitação, nomeada-mente originar fadiga ou mesmo a impossibilidade do utilizador ter o braço suspenso no ar, devido a limitações físicas. A configuração destes aparelhos e adaptação ao AV não é trivial.
3.4.1.3 Rato 3D
Estes dispositivos são ratos com seis graus de liberdade, são precisos, suaves, estáveis e não necessitam a deslocação física do rato [Zha98]. No entanto, são muito sensíveis e é necessário uma interação minuciosa com grande recurso aos dedos, o que à partida invalida sua utilização no âmbito desta Dissertação.
Estes dispositivos têm vantagens, especialmente no domínio do desenho assistido a computador e modelação 3D. Estudos mostram que mais de 84% dos utilizadores afirmam ter melhorias ao nível dos produtos desenvolvidos, um ganho de produtividade médio de 21%, com um curva de aprendizagem média de menos de um mês [Gro08]. Outra mais
valia é o decréscimo nas dores e desconforto relacionados com a utilização excessiva do rato [ME05].
Figura 3.5: Movimentos num rato 3D, adaptado de [3Dc]
A Figura3.5mostra as ações possíveis, o rato possui 6 graus de liberdade, três rotações e três translações.
3.4.2 Dispositivos de saída
Um dispositivo de saída é uma componente de hardware utilizada para comunicar o resultado do processamento de um sistema informático, o dispositivo de saída gráfico convencional é o monitor. No entanto, novos equipamentos permitem um maior grau de imersão.
3.4.2.1 Sistemas 3D
Na atualidade existem dois sistemas de visualização 3D de vídeo no mercado, o sis-tema Active Shutter (persiana ativa, em português) e o sissis-tema de polarização, ambos os sistemas 3D são baseadas em visualização estereoscópica de imagens, i.e., são mostradas duas imagens com perspetivas ligeiramente diferentes a cada olho [WY06]. Ambos os sistemas requerem óculos e um monitor.
O sistema de polarização de imagens, também denominado 3D passivo explora as características da luz para controlar o que é visualizado em cada olho. O LCD possui um filtro polarizado com duas orientações, uma para o olho direito e uma para o olho esquerdo, de acordo com as linhas pares e impares do LCD. Com a utilização de óculos polarizados, o utilizador filtra as linhas do olho contrário, vendo duas imagens diferentes em cada olho [Wol12]. Este processo está representado na Figura3.6.
No sistema Active Shutter (ou sistema de sequenciação alternada de frames), o uti-lizador usa uns óculos LCS (Liquid Crystal Shutter) [TH86, Edw09]. Cada lente destes óculos contém um cristal líquido transparente que se torna escuro quando submetido a voltagem. As lentes escurecem alternadamente em sincronia com a frequência de atuali-zação do LCD, produzindo a sensação de tridimensionalidade.
A NVIDIA lançou recentemente o Nvidia 3D Vision, um kit para jogos estereoscópi-cos que consiste num par de óculos LCS e drivers que permitem que a placa gráfica faça o render em 3D para qualquer jogo com Direct3D [NVIa]. No entanto, os fabricantes
Ferramentas
Figura 3.6: Síntese de uma imagem estereoscópica num sistema de polarização de imagem
estão divididos. A Mitsubishi, Panasonic, Samsung e Sharp optaram pelo sistema Ac-tive Shutter, enquanto a LG promove o sistema de polarização, a Toshiba e a Vizio têm equipamentos de ambas as tecnologias [Sil].
As vantagens do sistema Active Shutter são proporcionar uma resolução de imagem duas vezes superior à do sistema de polarização. A desvantagem é que pode causar des-conforto devido ao piscar das persianas que pode ser detetado por alguns utilizadores, adicionalmente é mais dispendioso, os óculos são mais pesados e requerem carregamento da bateria. No âmbito desta dissertação qualquer um dos sistemas poderia ser integrado, apesar de por uma questão de conforto fosse melhor optar pelo sistema de polarização. A integração seria possível uma vez que o Unity (Seção3.3) tem suporte para este tipo de dispositivos.
3.4.2.2 Oculus Rift
O Oculus Rift [VR] é um dispositivo híbrido, de entrada e saída de informação. Ape-sar de estar apenas disponível por pré-reserva, é relevante no contexto desta dissertação devido ao carácter inovador e ao elevadíssimo nível de imersão que proporciona. É um capacete que faz rendering 3D estereoscópico num campo de visão (FOV) vertical de 110oe horizontal de 90o, com sensor de movimento da cabeça com 6 graus de liberdade com uma latência negligenciável. O SDK (Software Development Kit) vai ter integração com o Unity [Kic,VR]. Uma série de títulos da indústria dos videojogos já confirmaram versões compatíveis com o Oculus Rift.
A utilização deste dispositivo no domínio desta dissertação seria interessante, devido à imersão que proporciona e porque resolve um problema verificado no uso de joysticks para a orientação no AV, a fadiga resultante de ter o braço levantado durante um período prolongado.
3.5
Sumário
O estudo das diferentes ferramentas tanto ao nível dos periféricos como ao nível dos motores de jogo é importante para melhor escolha da combinação de tecnologias para o desenvolvimento do projeto.
No âmbito desta Dissertação será utilizado o motor Unity. Após a análise do Unity conclui-se que é uma ferramenta completa e de rápida produção. A Asset Store pode vir a mostrar-se útil na aquisição gratuita de recursos que podem melhorar a qualidade do Jogo Sério e minimizar o tempo despendido em desenvolvimento.
A utilização dos periféricos de entrada cingir-se-á à utilização do joystick e do teclado e rato. Quanto a dispositivos de saída, a integração é possível uma vez que o Unity é altamente compatível com dispositivos de reprodução 3D.
Capítulo 4
Cidade Virtual
O projeto Cidade Virtual foi iniciado no âmbito da Dissertação de Mestrado “Jogo Sério para a Reabilitação Neurocognitiva: Cidade Virtual”, por Maria João Pinto Luís Miranda [Mir12]. No decorrer dessa Dissertação recolheram-se e documentaram-se re-quisitos (na forma de casos de uso), desenhou-se a arquitetura, estabeleceu-se a base de dados e criou-se a representação tridimensional da Cidade Virtual (através do CityEngine [Zur]). Já no âmbito desta Dissertação implementou-se o funcionamento e jogabilidade base em Unity. Este capítulo tem como propósito apresentar a estrutura e algumas das funcionalidades implementadas.
4.1
Conceitos
O protótipo desenvolvido consiste numa cidade tridimensional onde uma pessoa que sofre de LCA deve planificar e realizar uma série de tarefas. Nesta seção serão abordadas algumas das entidades e conceitos definidos no âmbito do projeto Cidade Virtual.
Cenário É uma representação tridimensional das cidades de Gaia e Porto, a Figura4.1
mostra o mapa numa vista bidimensional. O cenário é composto por lotes de várias categorias.
Lote É uma área do cenário, os lotes estão divididos em categorias: Comércio (padaria, florista, mercearia), Serviços (banco e correios), Lazer (jardins) e Social(residência e café). Os lotes implementados são os jardins, correios e residência.
Transportes São uma forma de o jogador se movimentar rapidamente na Cidade Virtual. Os transportes previstos são: carro pessoal, táxi, metro, comboio e autocarro. O único transporte implementado foi o autocarro. O carro apenas se poderá deslocar
de casa até um parque de estacionamento, os restantes transportes movimentam-se entre paragens e estações.
Sessão Uma sessão é uma utilização isolada da aplicação por parte do paciente. Há a possibilidade deste iniciar uma nova sessão ou retomar uma sessão anterior. Uma sessão pode incluir vários níveis e vários patamares. Uma sessão começa num pa-tamar à escolha do utilizador, assumindo que este o desbloqueou.
Patamar É um conjunto de níveis com o mesmo desafio. Os patamares são retroativa-mente cumulativos, i.e., um patamar exige os conhecimentos adquiridos no patamar anterior, desta forma a dificuldade é incremental. Os patamares previstos são: Ho-rário de Funcionamento, Grau de Importância, Caminho mais Curto, Transportes, Orçamento Limitado, Contra-relógio e Procura de Soluções.
Feedback Informação sobre a performance num nível. Pode ser de três tipos: instantâneo (na sequência da ação) periódico (tipicamente no final de cada nível, patamar ou sessão) e requisitado (consulta de informações adicionais e análise do progresso do jogador). Em termos de implementação apenas existem os feedbacks instantâneos e periódicos através de elementos de interface.
Figura 4.1: Planta bidimensional da Cidade Virtual, cores representam lotes diferentes
4.2
Mecânica do Jogo
A FiguraA.1no AnexoAmostra o fluxo de atividades do sistema e descreve os even-tos possíveis na mecânica final do jogo. A azul encontram-se as ações implementadas
Cidade Virtual
neste momento. Ou seja, é possível iniciar sessões de tratamento com diferentes utiliza-dores, planificar as tarefas dos diversos níveis e executa-las. A sequenciação dos diversos níveis e a progressão temporal também está funcional.
Inicialmente é apresentado um menu ao jogador, a Figura4.2mostra um exemplo de um desses elementos de interface, onde são facultadas informações sobre como planear as tarefas específicas do conjunto nível/patamar atual, onde o jogador deve ordenar as tarefas de acordo com esse(s) critério(s). Após a ordenação correta, o jogador entra no modo de Open Worldnuma perspetiva de primeira pessoa (FPP), usando as teclas direcionais para movimentação do avatar e o rato para orientar o movimento da câmara.
Figura 4.2: Menu de planeamento relativo ao quarto nível, com limite temporal.
Neste momento é possível a seleção dos lotes por via de um clique no botão esquerdo do rato. Isto despoleta uma janela de interface onde o jogador deve confirmar se o lote selecionado corresponde à tarefa a realizar. Esta ação dá origem a um feedback, que no caso afirmativo permite o jogador prosseguir para a realização da próxima tarefa. Durante este processo é possível consultar o mapa bidimensional da cidade.
No âmbito desta Dissertação foi necessário adicionar vários módulos de interface, como é o caso da gestão de utilizadores. É ainda necessário implementar consulta das informações e performance dos jogadores de forma a que essas informações sejam aces-síveis ao utilizador.
4.3
Arquitetura
Figura 4.3: Diagrama de pacotes
Foi necessário estudar a arquitetura do sistema para melhor perceber de que forma integrar as novas funcionalidades de uma forma modular. A Figura4.3mostra as classes e relações do sistema agrupadas em pacotes. O bloco “Interação” é responsável pela con-figuração e gestão das interações com o utilizador (i.e. rato e teclado). Existem também classes responsáveis pelo Graphical User Interface (GUI).
O armazenamento e manipulação dos dados resultantes do decorrer dos níveis/pata-mares é feito com a utilização das classes do bloco “BD_ Acesso”.
Os módulos de “Nível” e “Sessão” são responsáveis pela implementação da estrutura e regras do jogo, servindo muitas vezes de componente de ligação entre o acesso à base de dados e os outros blocos.
4.3.1 Base de Dados
A Cidade Virtual usa uma base de dados em mySQL. As figurasA.2eA.3apresentam a organização da base de dados.
A listagem com a explicação das entidades da base de dados encontra-se detalhada-mente documentada [Mir12], como tal, não se justifica especificar nesta Dissertação. No entanto, há uma entidade que requer especial atenção, a entidade “performance”, associ-ada às sessões (“sessions”) e aos níveis (“levels”) que guarda apenas o tempo decorrido e uma string(sequência de caracteres) com a prestação qualitativa.
A comunicação entre a base de dados mySQL e o Unity é feita via http por intermédio de um servidor php.
Cidade Virtual
4.4
Jogabilidade
O desenvolvimento do protótipo implicou a preocupação com pormenores que na tota-lidade contribuem para proporcionar uma jogabitota-lidade imersiva. Nesta seção expõem-se sumariamente algumas dessas funcionalidades.
4.4.1 Picking
Picking é a implementação do ato do jogador selecionar um objeto no AV. Para con-cretizar uma tarefa é necessário selecionar o lote respetivo, i.e., para realizar a tarefa “Comprar flores” o jogador deve deslocar-se e selecionar um edifício do tipo “Florista”. Para selecionar um edifício é necessário estar nas imediações deste, esta limitação é evi-dente por intermédio do interface, quando a distancia não permite interação, esta é exibida a vermelho.
4.4.2 Métricas de Performance
O sistema tem um mecanismo de adaptação à evolução do paciente. Se o jogador obtiver uma classificação igual ou superior a 80% na execução das tarefas três vezes consecutivas, passa automaticamente para o patamar seguinte.
Está previsto que quanto à avaliação do patamar “Caminho mais Curto”, ao longo do percurso do jogador sejam introduzidos num array as posições do jogador para calcular o desvio do caminho realizado em relação ao percurso em linha reta entre as diferentes tarefas. Em termos de implementação é ainda necessário introduzir essas informações na base de dados.
4.4.3 Sistema de autocarros
O sistema de autocarros serve de modelo para a implementação dos outros transpor-tes. Não é visível a deslocação do autocarro, este aparece e desaparece. A atribuição de paragens aos autocarros pode ser feita diretamente na base de dados.
O desenvolvimento do comboio e do metro deverão seguir uma estrutura semelhante ao transporte por autocarro. Para o transporte por táxi será introduzido um elemento de interface que permita chamar o táxi e o transporte no carro pessoal terá de permitir a seleção, no mapa da cidade, do parque de estacionamento que se pretende utilizar, alter-nativamente poder-se-á escolher o nome do parque numa lista.
4.4.4 Cálculo do percurso mais rápido
Um dos patamares prevê o cálculo do percurso mais rápido. A solução anteriormente proposta foi a instanciação de objetos dummy invisíveis, do tipo “prefab placer” (que têm por default uma tag de flag o que permite o seu acesso através de pesquisa por flag).
O problema era em termos de desempenho do sistema, esses objetos eram instancia-dos num loop Update de um script em javascript. Isto quer dizer que o cliente de jogo estaria constantemente a instanciar entidades, um cliente que execute em hardware com especificações técnicas superiores instanciará mais entidades do que um cliente com es-pecificações mais modestas. Adicionalmente, se o jogador se encontrar parado o cliente continuaria a instanciar entidades. Um cliente que executasse o jogo durante mais tempo teria o cenário de jogo densamente povoado destas entidades.
A solução adotada que é a mais eficaz em termos de performance foi introduzir as coordenadas do avatar do jogador num container (array) à medida que o tempo decorre (de segundo a segundo). Os cálculos podem assim ser baseados nos valores desse array sem comprometer a performance do cliente de jogo.
4.4.5 Modos de interface
Existe um script de interface, em C#, responsável por manter o modo de interface ativo que se encontra no diretório “/GUI”. Há dois modos de interface, o modo navegação onde o avatar e a câmara se movimentam e o modo interface onde o jogador seleciona elemen-tos de interface e objeelemen-tos visíveis na área de visão da câmara. Foi criada esta distinção uma vez que, sem estes modos a simples ação de carregar num botão (e.g., o botão de um menu de jogo) orientaria a câmara num determinado sentido. Por norma em qualquer FPSa interação com um menu de jogo desativa a possibilidade de movimentar a câmara, um exemplo comum é na aquisição de armas (como no caso de um jogo de combate) surgir um cursor que normalmente não está visível e ser desativada a possibilidade de movimentar a câmara.
A ativação é feita através da ativação de uma tecla ou botão de joystick. Como esta será a tecla mais utilizada, foi escolhida a tecla de espaço que é a de mais fácil acesso para pessoas com limitações motoras.
4.4.6 Iluminação
A iluminação é um aspeto essencial em computação gráfica. Em Unity é possível configurar vários tipos de luzes. A sua configuração altera significativamente a aspeto do cenário como é visível nas Figuras4.4e4.5.
Para atingir o efeito visível na figura4.5foi necessário definir as normais dos modelos dos edifícios, caso contrário a luz apenas seria refletida verticalmente.
Cidade Virtual
Figura 4.4: Screenshot antes das otimizações de luminosidade.
Figura 4.5: Screenshot depois das otimizações de luminosidade.
O efeito de luz alcançado foi possível através da colocação de um ponto de luz dire-cional, de cor branca que simula o Sol e pela configuração uma luz ambiente através dos rendering settingsdo Unity.
Figura 4.6: Screenshot onde é visível o nevoeiro.
4.4.7 Sons
O protótipo inclui três tipos de sons. Música ambiente, que numa fase posterior pode ser substituída por som ambiente de uma cidade. Sons do avatar cujo objetivo é aumentar a imersão, estes são o som da respiração e dos passos do jogador. E sons de interface, que são tocados quando o jogador ativa um elemento de interface (e.g., um botão). A gestão dos sons é feita a partir da classe SoundManager.cs.
4.4.8 Monobehaviours e Gameobjects
Muitos dos scripts utilizados no desenvolvimento do protótipo foram monobehavi-ours, em Unity a utilização de monobehaviours não deve ser feita através da instanciação convencional (linha 1 da listagem abaixo), deve antes ser feita através da atribuição a um componente (linha 2 da listagem abaixo).
1 S o m e C l a s s f o o = new S o m e C l a s s ( ) ; 2 MyClass b a r =
( MyClass ) someGameObject . AddComponent (t y p e o f( MyClass ) ) ; Isto porque um monobehaviour descreve um comportamento de um gameobject. Um gameobject representa uma entidade de uma cena em Unity. O acesso a gameob-jectspode ser feito de várias formas. A forma mais comum, especialmente para iniciados
Cidade Virtual
em Unity, é passar os gameobjects como argumento. Ou seja, num determinado gameob-ject(gameobject pai) coloca-se um script com um campo público, onde se tem controlo sobre outro gameobject (gameobject filho) que é passado como argumento.
Esta abordagem funciona, mas não torna os scripts modulares, ou seja, se colocarmos o gameobject pai numa cena diferente será necessário fazer a atribuição manualmente porque o gameobject filho já não se encontra em cena no inicio da execução do script do gameobjectpai. Uma abordagem programática e modular é fazer uma pesquisa pela tag do objeto desejado. Essa foi a abordagem adotada no desenvolvimento do protótipo.
4.5
Sumário
A nível gráfico, a modelação da cidade estava realista e permitia uma experiência imersiva de acordo com a realidade portuguesa. Foram documentados requisitos, arquite-tura e desenho da base de dados ao ponto de estabelecer uma base para a persecução dos objetivos desta Dissertação.
O desenvolvimento de um jogo com as características especificadas é um projeto de grande magnitude, onde prevalecem detalhes de implementação que podem dificultar a sua utilização pelo público alvo. O principal objetivo desta Dissertação foi a implemen-tação da Cidade Virtual, de forma a obter um protótipo usável para que fosse possível conduzir testes de usabilidade.
Capítulo 5
Interface Gráfica
Uma interface gráfica de utilizador (GUI) corresponde a uma interface que permite a interação com aparelhos eletrónicos com recurso a elementos visuais. Muitos aspetos do desenvolvimento de GUIs para jogos são conhecidos e difundidos na indústria, apesar de ser um tema latente na literatura. A diferença entre uma interface de excelência e uma improvisada no final de um projeto não se cinge ao domínio estético, para o utilizador, a aplicação é a interface,isto porque para ele, é a camada de interação mais externamente visível de qualquer sistema de software, e onde mais frequentemente se tornam evidentes possíveis fragilidades.
No campo da reabilitação neurocognitiva, por norma, a falta de familiarização com GUIse dispositivos de interação convencionais por parte dos utilizadores, aliada a possí-veis limitações físicas, visuais e cognitivas, tornam a tarefa de desenvolver uma GUI um desafio exigente.
Nos jogos digitais, um elemento fundamental na GUI é o Heads-Up Display (HUD), uma camada de GUI que se sobrepõe ao ambiente de jogo de uma forma persistente, permitindo um acesso constante à informação do jogo sem comprometer a sua fluidez, i.e., sem gerar interrupções para disponibilizar a informação ao utilizador.
A utilização de HUDs é discutível devido ao facto de haver um elemento de inter-face que constantemente obstrui a visibilidade do mundo de jogo podendo constituir uma constante lembrança que se está a interagir num ambiente virtual. Adicionalmente um HUD excessivamente complexo tem a desvantagem de poder intimidar o jogador mais inexperiente.
Neste caso, as desvantagens de usar um HUD são ultrapassadas pelas vantagens, i.e., transmitir informação essencial ao jogador, como por exemplo, as tarefas a realizar, os nomes dos edifícios e a hora no mundo de jogo. No entanto, prevê-se a ocultação opcional destes elementos, permitindo uma experiência mais realista.
5.1
Modos de interface
No jogo desenvolvido a perspetiva gráfica utilizada é na primeira pessoa, i.e., o joga-dor vê o mundo de jogo através dos olhos da personagem de jogo (avatar). Em termos de estilos convencionais, o jogo aproxima-se mais de um Role-Playing Game (RPG), ou seja, um jogo em que o jogador assume o papel do avatar que deve levar a cabo uma mis-são ou conjunto de tarefas, cujo sucesso ou insucesso mis-são determinados por um sistema de regras e diretrizes. No caso do protótipo desenvolvido, os objetivos a concretizar são explícitos, i.e., as tarefas a realizar são conhecidas do jogador.
Há, portanto, estas duas dimensões, navegação no mundo de jogo e gestão das tarefas a realizar. Na indústria dos videojogos existem vários RPGs com perspetiva na primeira pessoa, que ao nível do fluxo de jogo e da interface podem servir de inspiração.
No entanto, como o fluxo do jogo desenvolvido não está sujeito a constantes eventos de ação, foi decidido incorporar dois modos de interface distintos:
Modo Navegação A câmara e o avatar movimentam-se.
Modo Seleção A câmara e o avatar permanecem estáticos e é possível interagir com ele-mentos de interface com recurso ao cursor.
Em ambos os modos é possível inspecionar e interagir com o mundo de jogo, por exemplo, é possível selecionar um edifício que consta na lista de tarefas a realizar. A razão para a incorporação do modo de seleção prende-se essencialmente com a necessidade de “reduzir o ritmo” do jogo, e permitir que o jogador com toda a calma e atenção inspecione os elementos do mundo de jogo, sem ter que lidar com a movimentação da câmara. Este é um aspeto que raramente se encontra num jogo tradicional deste tipo.
A alternação dos modos de jogo é feita pela tecla de espaço quando se utiliza o teclado (por ser a tecla de mais fácil acesso devido à sua dimensão) e por um botão dependente da configuração em joystick).
5.1.1 Implementação
O estado atual do jogo é registado num enum que é utilizado no decorrer da aplicação para aferir o seu estado:
1 p r i v a t e enum S t a t e { l o a d , l o g i n , p l a n , n a v i g a t e , s e l e c t } ;
2 p r i v a t e S t a t e s t a t e ;
No ciclo de atualização do jogo, na classe Game, de acordo com o estado desse enum é verificado o estado dos periféricos quanto à comutação entre os dois modos de jogo.
Interface Gráfica
Figura 5.1: Botões relativos aos patamares.
Quando o evento do periférico decorre para ativar o modo de navegação, o cursor é blo-queado no centro do ecrã, e ativam-se os Monobehaviours responsáveis pela movimen-tação do avatar e da câmara associados ao gameobject do avatar - FPSInputController, MoveCamera, CharacterMotor.
Os diferentes modos também implicam diversas alterações no resto do programa, por exemplo, o tipo de cursor que é exibido.
5.2
Botões
Um botão é um elemento de interface que permite despoletar um evento. A caracterís-tica mais importante num botão é parecer um botão, isto é, deixar claro pela sua aparência que despoleta um evento. Como no caso do jogo desenvolvido os utilizadores poderão ter dificuldades adicionais foi tomada a decisão de usar botões de grande dimensão, para aumentar a visibilidade e facilitar a sua seleção.
Também é importante que os botões sejam responsivos, i.e., quando se pressiona um botão, espera-se que algo aconteça. Este feedback é essencial para proporcionar maior sensação de interatividade e evitar a confusão do jogador.
No jogo desenvolvido utilizaram-se vários elementos visuais, os botões têm duas apa-rências que inequivocamente identificam o estado do botão (pressionado ou não, como é visível na Figura5.1) e utilizam-se também elementos sonoros, por exemplo, apenas é possível jogar após o planeamento, se o planeamento não for válido o clique no botão de jogar produz um som de inação.
No caso específico dos botões relativos aos patamares do jogo foi necessário identifi-car qual o patamar atual, i.e., o patamar que o jogador ainda não completou na totalidade, assim como, deixar claro quais os patamares que ainda não foram desbloqueados. Na figura5.1os três primeiros patamares estão desbloqueados, os dois primeiros foram ter-minados, o segundo está selecionado, os três últimos estão bloqueados.
