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 objetos 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 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.

5.2.1 Implementação

Alguns botões foram implementados com utilização direta da classe GUI.Button do Unity. Outros não são implementados de forma trivial, por exemplo, o desenho dos botões de patamar está definido na classe BlockButton:

1 p u b l i c v o i d OnGUI ( ) { 2 B l o c k T y p e u s e r B l o c k = u s e r M a n a g e r . g e t U s e r ( ) . g e t B l o c k ( ) ; 3 i n t u s e r B l o c k N = u s e r B l o c k . t o I n t ( ) ; 4 i n t b l o c k N = b l o c k . t o I n t ( ) ; 5 6 i f ( u s e r B l o c k N >= b l o c k N ) { 7 s t r i n g s u f f i x = p r e s s e d ?" p r e s s e d ":" n o r m a l "; 8 i f ( GUI . B u t t o n ( box , " " , s k i n . G e t S t y l e (" b l o c k " + b l o c k . t o I n t ( ) + " _ " + s u f f i x ) ) ) { 9 s o u n d M a n a g e r . p l a y C l i c k ( ! p r e s s e d ) ; 10 p r e s s e d = ! p r e s s e d ; 11 } 12 i f ( u s e r B l o c k ! = b l o c k ) {

13 GUI . D r a w T e x t u r e ( cupBox , cup ) ;

14 } 15 }e l s e{ 16 GUI . B u t t o n ( box , " " , s k i n . G e t S t y l e (" b l o c k " + b l o c k . t o I n t ( ) + " _ d i s a b l e d ") ) ; 17 } 18 }

Nas linhas 8 e 16 os botões são criados com base num GUIStyle de Unity (é o terceiro argumento da chamada ao método Button) de acordo com o seu estado. A vantagem desta abordagem é a possibilidade de mudar completamente o aspeto visual dos elementos de interface, apenas por manipulação ou substituição do ficheiro do GUIStyle, sem ser necessário alterar o código, separando a lógica da apresentação.

5.3

Menus

Um menu é um elemento de interface utilizado para organizar informação. Ao entrar no jogo o jogador depara-se com um menu onde deve selecionar o seu utilizador e o patamar em que pretende jogar (menu Login). De seguida são mostrados os detalhes relativos ao nível a levar a cabo, onde o jogador planifica e ordena as tarefas a realizar,

Interface Gráfica

com base em informação sobre as mesmas (menu Plan). Neste último o jogador altera a ordem das tarefas com recurso a setas. As setas são de cores diferentes para facilitar a sua distinção. Se a posição de uma tarefa corresponder ao fim ou início da lista, as setas ficam cinzentas para representar a impossibilidade de mudar a sua ordem na lista.

5.3.1 Implementação

Cada menu tem uma classe responsável pelo seu desenho e gestão. Essas classes não são Monobehaviours, implementam o interface IMenu, que foi definido da seguinte forma:

1 i n t e r f a c e IMenu { 2 v o i d OnGUI ( ) ; 3 b o o l i s D o n e ( ) ; 4 }

Nos construtores destas classes inicializam-se as posições dos elementos de interface, tipicamente sob a forma da estrutura de Unity para definir retângulos, Rec. O construtor guarda entre outras estruturas, a GUISkin a utilizar neste menu, onde são definidos todos os elementos gráficos a utilizar. De seguida no método OnGUI desenham-se os elementos de interface. Este método deve ser evocado no método OnGUI da classe Game. O método isDonedevolve verdadeiro quando o menu termina, por exemplo, quando no menu Plan as tarefas foram ordenadas corretamente e se carregou no botão “Jogar”.

5.4

Cursores

Os cursores do rato são um elemento importante para proporcionar feedback das ações do jogador, especialmente em relação ao tipo de elemento ou ação que será despoletada após o clique do rato. Foram implementados três tipos de cursor, como é visível na Figura

5.2. O primeiro é o cursor do modo de navegação, o segundo é o do modo de seleção e o terceiro surge quando o jogador se encontra a uma distância que permita interação com o edifício (o jogador não pode interagir com um edifício assim que este seja visível, deve aproximar-se até estar em alcance do edifício) e indica a passagem desse edifício para a lista de tarefas à direita.

Houve especial cuidado em representar os cursores em tamanho grande para reconhe- cimento inequívoco, uma vez que os jogadores poderão apresentar défices a nível visual.