• Nenhum resultado encontrado

4. Projeto “Mestre Dentinho”

4.1 Conceito

Sempre se soube que as crianças têm um certo receio de ir ao dentista, às vezes por terem medo dos barulhos das máquinas, medo dos aparelhos que as rodeiam, medo das dores e, às vezes, também por ouvirem histórias e mitos acerca dos dentistas. Este receio, pode levar a criança a não querer ir ao dentista ou a ir contra a sua vontade, dificultando a intervenção do médico(a) dentista. Os ambientes virtuais podem ser utilizados para distrair as crianças através de jogos que as envolvam de forma a reduzir essa ansiedade e também de forma a abstraí-las do que está a acontecer durante o procedimento, fazendo com que a criança perca esse receio de ir ao dentista e obtenha uma melhor saúde oral.

Nos dias de hoje, já existem bastantes métodos de RV para tratamento de fobias recorrendo a aplicações não interativas. Porém, conhecem-se poucos métodos que recorram a aplicações interativas ou jogos. Um dos poucos exemplos da utilização de um videojogo para realizar estes tratamentos é o “Veracity” (Marques, 2016).

Em adição, pouco se conhece para o tratamento da ansiedade causada pela ida ao dentista. As pessoas, no geral, não estão devidamente informadas das capacidades que a RV tem na ajuda psicológica para este tipo de situações, apenas conhecem a RV como uma tecnologia ao serviço da diversão/entretenimento e não como uma ferramenta para a resolução de problemas.

Com a RV podemos tornar as idas ao dentista interessantes, divertidas e didáticas para as crianças. Desta maneira, conseguimos com que a criança retire alguma experiência e não desista nem se aborreça de frequentar as tão importantes consultas.

Juntamente com a FMDUP, foi proposta a criação de uma solução tecnológica para este problema. Inicialmente, pensou-se em criar uma espécie de aplicação RV. Contudo, depois de analisar melhor e de se compreender a faixa etária do público-alvo, foi decidido criar algo mais interativo, como um videojogo de RM, que ligue as sensações do que está a acontecer durante o procedimento. O videojogo Mestre Dentinho é um jogo que serve apenas para o contexto da medicina dentária, visto que contém bastante conteúdo didático relativo a esta área. O objetivo é isolar o jogador para que ele se sinta completamente imerso na experiência, através da interação com as ações no jogo enquanto está a ser realizado um procedimento dentário.

Esta tecnologia tem como desafio cativar a atenção de todas as clínicas dentárias para a adoção do jogo. Esta tecnologia é, por isso, bastante acessível precisando de pouco investimento. Outro desafio importante desta aplicação é o uso mínimo de espaço para que o trabalho do profissional não seja comprometido.

4.1.1 Cenários

Este jogo, que se encontra pré-instalado no dispositivo de RV tem como componentes tecnológicos os óculos de RV e os comandos para controlar ações tais como: mudar de direção, saltar, redirecionar a camara e começar o jogo. Assim que o jogador começa a sessão/consulta, o videojogo começa também.

Não será necessária nenhuma intervenção do médico dentista, este apenas terá de dar as instruções do jogo, explicar como colocar os óculos e dar a ordem de início do jogo, para coordenar com o que vai acontecer na sessão.

Este projeto contém vários níveis que alteram conforme o tipo de sessão. Ou seja, o que acontece no nível do jogo está interligado com as sensações que o paciente está a sentir. Também estes níveis, servem para que o jogo nunca se torne aborrecido para o jogador quando este voltar em sessões futuras.

Estes níveis são caracterizados como sendo bastante didáticos, pois têm sempre o objetivo de ensinar algo à criança sobre a saúde oral. As mecânicas do jogo baseiam-se no estilo endless

runner, alterando apenas os elementos gráficos do cenário, dos obstáculos e das personagens em

cada nível e sessão. A dificuldade do jogo também não altera perante as sessões, porém, altera conforme o tempo que o jogador joga, fazendo assim com que o jogador nunca perca a vontade de voltar a jogar. Ao fim de todas as sessões o participante será parabenizado pela sua pontuação e avisado que na próxima sessão jogará um nível novo, ficando o jogador/paciente com vontade de voltar.

Os cenários são maioritariamente coloridos e cativantes para que a criança se sinta feliz ao jogar. Se a criança estiver entretida e feliz, não se apercebera do que se passa à sua volta.

4.1.2 Proposta de Valor

Este projeto apresenta duas importantes componentes presentes no mercado nos dias de hoje: os videojogos e a RV. Através da revisão da literatura conclui-se que cada vez mais a RV está presente na vida das pessoas. Ficou demonstrado que a RV se mostra bastante bem sucedida na psicoterapia e hoje, cada vez mais, se usa mais hardware de RV, e à medida que este se vai desenvolvendo o seu custo diminui, fazendo com que mais pessoas tenham acesso a este material e também este material. Acresce ainda dizer que a melhoria em termos de portabilidade, faz com que esta ferramenta possa ser usada em diversas situações/condições, o que era impensável há uns anos atrás. Outro facto importante é que com a RV a experiência do utilizador está cada vez mais próxima da realidade. Esta evolução vai permitir que a RV seja usada na medicina, em várias áreas, com benefícios para os pacientes, substituindo métodos mais rudimentares

Tendo em conta o referido, e não tendo conhecimento, até à data, de métodos específicos para resolver o tipo de problema que é proposto, este projeto “Mestre Dentinho” pretende inovar o uso desta tecnologia na medicina dentária.

4.2 Desenho e Implementação

Este projeto foi desenvolvido em três dimensões. Todos os seus cenários são baseados em ambientes reais. Estes cenários contêm elementos representativos como árvores, arbustos, muros, chão, pontes e nuvens. Ao longo do jogo, o jogador se apanhar todos os itens relacionados à boa pratica da saúde oral, tem ainda a opção de adquirir os seguintes bónus: escova de dentes, pasta de dentes e fruta; e os seguintes obstáculos: bactérias e rebuçados, que farão perder uma vida das cinco iniciais.

Os cenários são todos gerados procedimentalmente. É gerado um número inteiro entre zero e um número escolhido que quanto maior, menor a probabilidade de gerar o elemento pretendido. Depois, é comparado se esse número é igual a zero. Se a condição for verdadeira o elemento será gerado. Existe, ainda, uma variável que guarda o valor do vetor Z para poder, à medida que se avança, ser gerado novo conteúdo. Este algoritmo é bastante primário, porém resulta muito bem. Também a posição de todo o conteúdo é aleatória dentro de um limite de números.

4.2.1 Protótipo Inicial

Após a recolha de dados, foi desenhado e programado um protótipo básico com as mecânicas todas implementadas. A partir daí foram implementados o GUI, todos os gráficos do jogo e todas as mecânicas finais. Algumas das mecânicas e características pensadas e implementadas inicialmente, foram retiradas devido ao facto de tornarem o jogo menos jogável, não acrescentarem nada à jogabilidade e tornarem a experiência menos imersiva.

Figura 22 - Demonstração do primeiro protótipo

4.2.2 Jogabilidade

O jogo começa com uma cutscene, no consultório virtual, que liga a mudança do paciente do ambiente real para o ambiente virtual. De seguida, aparece o guia do jogo que o leva até ao começo do nível. Foi decidido não usar nenhum menu para tornar o começo do jogo simples e para não quebrar a sensação de imersão.

Figura 23 - Cutscene que apresenta a guia do jogo (Borboleta Carlota)

Depois da Cutscene, é apresentado o painel com as vidas do jogador e os pontos. Assim que começa o jogo, o jogador terá de começar logo a desviar-se dos obstáculos e apanhar os objetos saudáveis que lhe dão pontos.

Figura 24 - Inicio do jogo

Quanto mais tempo o jogador joga, mais rápido e mais difícil o jogo fica. A cada mil pontos, o jogador avança de nível. Para ajudar, sempre que é apanhado um objeto saudável, o jogador recebe 50 pontos e caso esteja sobre o efeito do Boost esse valor duplica e ganha uma vida.

Figura 25 - Começo do Nível 1

Para não perder as suas vidas, o jogador terá de evitar todos os pickups que são considerados como não sendo saudáveis. Caso embata num obstáculo estático, como por exemplo um muro, perderá todas as vidas. Assim que o jogador perde todas as suas vidas, voltará ao início e recomeçará automaticamente no nível zero, com zero pontos. A sua melhor pontuação fica guardada.

4.2.3 Elementos

Os elementos tridimensionais criados para este jogo, foram inspirados em Voxel Art, Comic Art e Low Poly Art, sugerindo um género minimalista e futurista e, ao mesmo tempo, apelativo e adequado para o público que pretende atingir.

Existem dois tipos de elementos, os interativos e os estáticos. Os elementos interativos são todos aqueles com que o jogador pode interagir e que ajudam na progressão ou regressão do jogo. Estas permitem que o jogo não se torne tão aborrecido, dando ao jogo objetivos.

Figura 26 - Elementos interativos modelados e usados

Os elementos estáticos são todos aqueles que servem apenas para fins de decoração. Para além de decoração, os elementos estáticos são importantes para tornar a experiência mais imersiva.

Figura 27 - Elementos estáticos modelados e usados

4.3 Descrição da Implementação

public override void _Process(float delta) {

var player = GetNode<Player>("Player"); if (player.isReady)

update_score(delta);

spawn_env();

if (GetTree().GetNodesInGroup("Env_Grounds").Count < 6) {

x_position_list = new List<int>() { -2, 0, 2 };

spawn_ground();

if (!boost_enabled) {

spawn_obstacle(); spawn_bonus_picker();

spawn_enemy();

spawn_healthy_picker(); spawn_unhealthy_picker(); }

}

O código supra mostrado, representa o loop principal do jogo onde são chamadas todas as funções para povoar o cenário. Começa por verificar se o jogador já assistiu à cutscene, para que a pontuação possa ser atualizada e o jogador possa começar a mover-se a partir do booleano “isReady”. É também gerado todo o meio ambiente do jogo que envolve as pistas, como as arvores, nuvens, etc., na função “spawn_env()”. Através da contagem do número de pistas existentes no jogo, se não exceder seis pistas, é gerado uma nova pista e logo de seguida é povoada aleatoriamente com inimigos, bónus e obstáculos. Tudo o que fica para trás é removido posteriormente com um check que verifica a distância a que está do jogador. Se for maior que a distancia definida, então será removido o objeto do jogo para evitar usar muitos recursos de memória. Caso o bónus esteja ativo os obstáculos não serão colocados.

private void spawn_obstacle() {

if (GD.Randi()%2 == 0) {

var z_position = (float)GD.RandRange(ground_position - 10, ground_position + 10);

if (last_obstacle_position >= z_position - 25 && last_obstacle_position <= z_position + 25)

return;

if (GD.Randi() % 2 == 0) {

var y_position = 4.5f;

var obstacleInstance = global.wall_obstacle_scene.Instance(); var Obstacle = obstacleInstance as Spatial;

Obstacle.Translation = new Vector3(0, y_position, z_position);

AddChild(Obstacle); } else { x_position_list.Clear(); var y_position = 5f;

var obstacleInstance = global.wall_obstacle2_scene.Instance(); var Obstacle = obstacleInstance as Spatial;

Obstacle.Translation = new Vector3(0, y_position, z_position);

last_obstacle_position = Obstacle.Translation.z; AddChild(Obstacle);

} }

}

O código acima mostra como funciona o algoritmo de geração procedimental para povoar o cenário. Primeiro, é decidido se o objeto será carregado no cenário. Caso seja, irá então buscar- se o valor do eixo do Z da posição da última pista colocada no cenário na variável “ground_position”. Depois, é feito o ajuste da posição do objeto já carregado em memória que vai ser posicionado numa posição aleatória ao longo do comprimento total da pista. Por fim. É adicionado ao nível. Todos os objetos colocados no nível, funcionam à base deste código. Este exemplo, em especifico, faz gerar e posicionar um obstáculo, onde temos uma probabilidade de 1 em 2, que esse objeto possa ser gerado, pois a função “GD.Randi()%2”, neste caso, gera um número aleatório de 0 a 1. O obstáculo é posicionado de acordo com a posição da pista e adicionado ao nível.

private void ProcessInput() {

var joystick_vector_left = new Vector2(-VR_Controller_Left.GetJoystickAxis(0), VR_Controller_Left.GetJoystickAxis(1));

if (joystick_vector_left.x > -0.5 && joystick_vector_left.x < 0.5) justTurned = false;

{

if (floor_is_colliding() || Translation.y > 1) if (end.x > -2 && !justTurned) {

end.x -= 2; justTurned = true; }

}

else if (Input.IsActionJustPressed("ui_left") || joystick_vector_left.x > 0.5) {

if (floor_is_colliding() || Translation.y > 1) if (end.x < 2 && !justTurned) {

end.x += 2; justTurned = true; }

}

else if (Input.IsActionJustPressed("ui_up") || joystick_vector_left.y > 0.7) {

if (floor_is_colliding())

velocity.y += JUMP_HEIGHT; }

else if (Input.IsActionJustPressed("ui_down") || joystick_vector_left.y < -0.7) {

if (!floor_is_colliding())

velocity.y -= JUMP_HEIGHT * 2.5f; }

var joystick_vector_right = new Vector2(-VR_Controller_Right.GetJoystickAxis(0), VR_Controller_Right.GetJoystickAxis(1)); float controllerSensitivity = 0.1f; if (joystick_vector_right.x < -0.5) { Camera.RotateX(-joystick_vector_right.x * controllerSensitivity); } else if (joystick_vector_right.x > 0.5) { Camera.RotateX(joystick_vector_right.x * controllerSensitivity);

} else if (joystick_vector_right.y > 0.5) { Camera.RotateY(joystick_vector_right.y * controllerSensitivity); } else if (joystick_vector_right.y < -0.5) { Camera.RotateY(-joystick_vector_right.y * controllerSensitivity); } }

Quanto à interação, o jogador pode controlar o movimento da personagem, possuindo apenas possibilidade de se mover em duas direções: no eixo do x e no eixo do y, para saltar e evitar alguns obstáculos, respetivamente. Ao movimentar o joystick do comando esquerdo para a direita ou esquerda, o jogador movimentar-se-á para uma das 3 posições possíveis, para evitar embater nos obstáculos. Se o jogador mover o joystick para cima, o character saltará; se o mover para baixo, o jogador irá mais rápido para baixo caso esteja a saltar. Existe também a possibilidade de através do uso do joystick do comando direito, o utilizador rodar a câmara em todas as direções já que não é possível movimentar a cabeça para observar o ambiente virtual.

A animação de abertura foi criada através deste motor de jogo. Este proporciona um node chamado AnimationPlayer que permite fazer qualquer tipo de animação através de keyframes e é uma boa alternativa ao Blender em termos de animação. Também é possível fazer a animação no Blender e importar diretamente no engine através da exportação para o formato “.gltf”.

As restantes animações, como por exemplo os inimigos, foram feitas juntamente com o modelo no Blender e exportado para o Godot em “.gltf”.

Figura 29 - Demonstração da animação da Borboleta Carlota no Blender 2.8

4.4 Conclusão

Desde a conceção, desenho e implementação todos os níveis foram propostos não considerando uma grande aproximação à realidade uma vez que existem dois problemas associados. O vale da estranheza (Uncanny Valley) identifica que quanto mais detalhes são percetíveis ao olho humano menor é o distanciamento da realidade (Tinwell, 2014). Os enjoos de movimento (Motion Sickness) aparecem devido à observação do meio que nos rodeia confundindo o nosso sentido de perceção e orientação. Por exemplo, estar a visualizar um cenário em movimento quando na realidade nos encontramos sentados no sofá. Por conseguinte, é ainda referido na literatura que ao se avaliarem aplicações que contenham ambientes próximos da realidade, se sentem certos desconfortos, tais como desequilíbrio, dores de cabeça ou náuseas.

Uma forma de minimizar este problema consiste no uso de gráficos que introduzam imperfeições que diferenciem os cenários virtuais da realidade. Assim, não é necessário remover conteúdo interativo que contribua para uma melhor imersão e que ajude a obter uma boa experiência de RV. Esta é a razão pela qual se optou neste projeto por tipos de gráficos “Voxel” e “Comic” que diferenciam a perceção do participante para algo lúdico e artificial.

No que diz respeito à física do jogo, foram implementadas mecânicas para circundar limitações relativas à prática deste projeto, num ambiente restrito como um consultório médico. Uma vez que não pode haver movimentos de qualquer forma, durante um procedimento dentário,

optou-se por criar limitações no ambiente virtual que evitem que o paciente se mova na cadeira. Em parte, algumas das funções que a RV disponibiliza por defeito, tais como: a rotação 360º, o movimento espacial e o movimento dos comandos foram desativadas para não interferir no tratamento do paciente e, assim, evitar problemas no procedimento que poderia causar danos irreparáveis. Em suma, o jogo “Mestre Dentinho” potência a concentração da criança em tratamento e auxilia o trabalho do profissional não só a nível das fobias como também evita a agitação.

5. Resultados e Discussão de

No documento Ambientes Imersivos na Medicina Dentária (páginas 59-75)

Documentos relacionados