Interface Digital para Avaliação Pós-Ocupação em Habitação utilizando Unity3D e Blender

Transcrição

1 UNIVERSIDADE FEDERAL DE UBERLÂNDIA Danilo Bizinotto Borges Interface Digital para Avaliação Pós-Ocupação em Habitação utilizando Unity3D e Blender Uberlândia, Brasil 2015

2 UNIVERSIDADE FEDERAL DE UBERLÂNDIA Danilo Bizinotto Borges Interface Digital para Avaliação Pós-Ocupação em Habitação utilizando Unity3D e Blender Trabalho de conclusão de curso apresentado à Faculdade de Computação da Universidade Federal de Uberlândia, Minas Gerais, como requisito exigido parcial à obtenção do grau de Bacharel em Ciência da Computação. Orientador: Prof. Dr. Maria Adriana Vidigal Lima Universidade Federal de Uberlândia UFU Faculdade de Ciência da Computação Bacharelado em Ciência da Computação Uberlândia, Brasil 2015

3 Danilo Bizinotto Borges Interface Digital para Avaliação Pós-Ocupação em Habitação utilizando Unity3D e Blender Trabalho de conclusão de curso apresentado à Faculdade de Computação da Universidade Federal de Uberlândia, Minas Gerais, como requisito exigido parcial à obtenção do grau de Bacharel em Ciência da Computação. Trabalho aprovado. Uberlândia, Brasil, 21 de Julho de 2015: Prof. Dr. Maria Adriana Vidigal Lima Orientador Prof. Dr. Pedro Frosi Rosa Professor Prof. Dr. Fabiano Azevedo Dorça Professor Uberlândia, Brasil 2015

4 Este trabalho é dedicado primeiramente a Deus que se fez presente em todos os momentos de minha vida. E à minha família a qual amo incondicionalmente e indefinidamente, por me fornecer todo suporte possível para que eu chegasse até aqui.

5 Agradecimentos Agradeço à professora Maria Adriana, que além de se tornar uma amiga, me aconselhou diversas vezes sabiamente a ser uma pessoa cada vez melhor a cada dia e por me reforçar que calma e paciência são essências fundamentais para a convivência em um grupo multidisciplinar. Aos meus pais, namorada e irmã que estiveram ao meu lado o tempo todo mesmo sem entenderem uma só linha de código. À universidade, pela oportunidade de mostrar o meu potencial. À toda equipe da APO Digital, não só pelo privilégio de ser um membro como também pelo companheirismo. Ao professor Pedro Frosi, pela amizade, por ter abrido as portas de um primeiro projeto que motivou minha chegada até aqui e por acolher a vontade de poucos e acreditar que os poucos um dia se tornarão grandes. A todos os amigos, que acreditaram e me ajudaram quando poucos o fariam. E à própria pesquisa em si, por me fornecer uma quantidade inestimável de conhecimento que sempre sonhei em adquirir

6 A maturidade do homem consiste em haver reencontrado a seriedade que tinha no jogo quando era criança., Friedrich Nietzsche

7 Resumo Pesquisas de Avaliação Pós-Ocupação são compostas por questões direcionadas a um determinado público de moradores, que respondem sobre suas condições de moradia, passadas e atuais, abordando também assuntos relacionados à área da arquitetura. A pesquisa tem como função coletar informações sobre a forma de morar deste público e detectar problemas relacionados à moradia atual, para que possam ser estudadas formas de sanálos. Os pesquisadores se deslocam até o local em que a avaliação será aplicada e, com uso do questionário impresso em papel, auxiliam os respondentes durante o processo. O questionário possui mais de 50 questões, fato que incomoda bastante quem se dispõe a colaborar com a pesquisa. Este projeto surge com a proposta de transformar o questionário impresso num jogo digital 3D aplicando aspectos de gamificação, este poderá ser acessado por meio da web e por aplicativos em dispositivos móveis. Na pele de um avatar, o respondente poderá navegar por uma ilha flutuante e a cada local por ele visitado, responder a uma parcela das perguntas, correspondente àquelas da avaliação, geralmente relacionadas ao próprio local representado digitalmente. O objetivo deste trabalho é incorporar ao jogo atributos lúdicos e divertidos que possam motivar a participação das pessoas na Avaliação Pós-Ocupação. O software será confeccionado utilizando-se a engine Unity3D sendo a parte gráfica modelada em Blender e Photoshop. A gerência do projeto será inspirada no Scrum, um método ágil que controlará o tempo de cada tarefa a ser realizadas, quais terão prioridade sobre as demais a serem implementadas e no controle do grupo multidisciplinar que desenvolverá o software. O Scrum é dividido em três etapas denominadas Pré-Produção, Produção e Pós-Produção, serão feitos estudos de viabilidade e criação, desenvolvimento e testes, respectivamente. A utilização de técnicas baseadas no estudo de Interfaces Humano-Computador será primordial na montagem das GUIs, trazendo benefícios em relação a comunicação entre o sistema e o usuário. Algoritmos implementando diferentes lógicas serão abordados, incluindo detalhes sobre a API (Application Programming Interface, ou Interface de Programação de Aplicativos) do motor Unity3D e descrições sobre seu funcionamento. Palavras-chave: Avaliação Pós-Ocupação, jogos digitais, questionário, Unity3D, Blender.

8 Lista de ilustrações Figura 1 Tela final do jogo Energuy, mostrando ao usuário os objetos encontrados e organizados Figura 2 Logo da engine de games Unity3D Figura 3 Coleta e mediação de requisitos feita pelos projetistas de jogo Figura 4 Fluxo de processo Scrum (PRESSMAN, 2014) Figura 5 Telas do jogo GTA II, desenvolvido pela Rockstar Games. A figura ilustra a confusão de direções que o jogador é exposto ao se mover para cima e para baixo Figura 6 Gráfico da análise do editor do Unity sobre a frequência de utilização das linguagens Boo, C# e UnityScript (ALEKSANDR, 2014) Figura 7 Tela da engine Unity em fase de produção do projeto Como Você Mora especificamente na cena de customização do personagem Figura 8 Personagem feito para o protótipo do jogo Como você mora na posição T ideal para futura animação Figura 9 Tela do Programa Adobe Photoshop CS4 apresentando diversar janelas abertas em paralelo, referentes a pintura do personagem, da igreja e uma paleta de cores Figura 10 Curva de interesse entre os anos de 2005 a A linha em azul trata da linguagem de programação C# usada na Unity, e a linha vermelha refere-se à linguagem usada no Adobe Flash, ActionScript Figura 11 Curva de interesse entre os anos de 2005 a A linha em azul trata de pesquisa pela engine Unity, e linha vermelha refere-se ao software Adobe Flash Figura 12 Classificação de palavras-chave em grupos de afinidades nas técnicas da APO Figura 13 Diagrama de classes da camada de modelo Figura 14 Fluxo de tarefas desempenhadas durante o projeto. A fase de storyboard corresponde à fase de Roteiro e Conteúdo Figura 15 Primeiro teste de modelagem feito no Google SketchUp para o ambiente do jogo Como Você Mora Figura 16 Ícones referentes aos softwares de modelagem 3D, 3ds Max, Cinema4D, Blender, SketchUp e Maya, respectivamente da esquerda para a direita 41 Figura 17 Cenários do jogo Monument Valley produzido pelo estúdio indie Ustwo 42 Figura 18 Esboço produzido para futuras modelagens da ilha flutuante Figura 19 O personagem Pesquisador modelado na ferramenta Blender Figura 20 Paleta com cores pastéis

9 Figura 21 Aparelhos Samsung Moment e Samsung Galaxy S Figura 22 Telas do game Flappy Bird e sua dinâmica Figura 23 Todas as partes customizáveis do avatar Figura 24 Ilha flutuante totalmente colorida Figura 25 Tela de customização do personagem e ao lado direito o vetor de materiais que estão associados à malha 3D naquele momento Figura 26 Parte do algoritmo de customização implementado na linguagem JavaScript(UnityScript), mostrando o conteúdo das funções OnGUI e ChangeBodyMaterial Figura 27 Parte do algoritmo de customização, mostrando como é feita a troca da textura da face do personagem, sem com que o material associado a ela seja também trocado Figura 28 Parte do algoritmo de customização, correspondente à função Change- MeshMaterial Figura 29 Visão de topo da ilha flutuante; os marcadores vermelhos identificam os pontos cujo o avatar fará uso em seu caminhamento Figura 30 Grafo com pontos utilizados na função de caminhamento do personagem. 57 Figura 31 Contrução da lista que contêm o caminho que o avatar percorrerá, dado o toque do usuário em alguma localidade Figura 32 Algoritmo de patrulha, feito para a movimentação do personagem dentre os pontos da ilha

10 Lista de tabelas Tabela 1 Exemplo de questão da APO apresentada aos moradores Tabela 2 Diferenças de hardware entre os modelos Samsung Moment e Galaxy S6 46 Tabela 3 Descrição do Conceito de Arte associado ao Personagem principal Tabela 4 Operação de modelagem Tabela 5 UV unwrap Tabela 6 UV mapping Tabela 7 Rigging Tabela 8 Weight Paint Tabela 9 Animação Tabela 10 Comparação entre botões padrões e estilizados na Unity

11 Sumário 1 INTRODUÇÃO Estado da Arte Hipótese Objetivo Justificativa METODOLOGIA REFERENCIAL TEÓRICO Engenharia de software aplicada a jogos Uso de Metodologias Ágeis no Desenvolvimento de Jogos Interface Humano-Computador Unity Interface e funcionalidades da Unity 3D Ferramentas de modelagem, animação e texturização Blender Produção do Personagem Produção do cenário Photoshop TRABALHOS CORRELATOS AVALIAÇÃO PÓS-OCUPAÇÃO Base de Dados da Avaliação Pós-Ocupação DESENVOLVIMENTO Gestão de projetos utilizando Scrum Pré-Produção Produção e Pós-Produção Pré-Produção e Viabilidade Viabilidade Técnica Viabilidade Artística e Fluidez Produção e Pós-Produção Hardware de dispositivos móveis com foco em jogos Processo de modelagem do personagem no Blender Processo de modelagem do Cenário Ambiente Unity e criação de cenas

12 6.3.5 Estilização das GUIs Prefabs Lógica de customização do personagem principal Lógica de caminhamento do personagem entre os componentes da Ilha flutuante Conclusão Referências

13 12 1 Introdução A Avaliação Pós-Ocupação (APO) em imóveis residenciais (VILLA, 2014) é o estudo do ambiente de casas e apartamentos, visando uma avaliação sistematizada do ambiente após passado algum tempo de sua construção e ocupação, com base em estatísticas geradas a partir de dados coletados em avaliações realizadas pelos próprios moradores. A avaliação tem o objetivo de analisar questões e necessidades apontadas por moradores e indicar possíveis melhorias nas moradias atuais e é também um instrumento útil para a implementação de melhorias em futuras edificações. A avaliação considera o ambiente imóvel, ou seja, o espaço interno que a moradia possui e também o estado em que ela se encontra, quanto a disposição dos móveis e suas reais utilidades, somando aspectos construtivos, condições de conforto, consumo energético, fluxo de pessoas e acessibilidade. Um dos instrumentos mais importantes da APO é uma pesquisa contendo aproximadamente cinquenta questões, abertas e fechadas. A aplicação desta pesquisa ocorre atualmente da seguinte maneira: o pesquisador se desloca até o alvo de pesquisa e na presença do morador procura preencher o questionário da melhor forma possível. O intuito é que o processo seja fácil e agradável para que o morador forneça uma quantidade razoável de informações. O projeto encontra-se em andamento na Faculdade de Arquitetura e Urbanismo da Universidade Federal de Uberlândia, e foi desenvolvida uma versão do questionário num sistema para tablet, a fim de substituir a função que os fórmulários impressos em papel já vinham desempenhando. Esta versão colaborou não apenas com a agilidade da pesquisa como também permitiu que os dados coletados durante a avaliação fossem transferidos e mantidos numa base de dados relacional, utilizada posteriormente para a realização de levantamentos estatísticos. Pretende-se que uma nova versão do sistema seja desenvolvida de forma a transformar o questionário tabular numa estrutura dinâmica que permita ao usuário navegar por uma projeção do espaço arquitetônico e responder a questões que seriam apresentadas no formato de um jogo interativo. O desenvolvimento da nova versão do sistema é o tema deste trabalho e as novas interfaces do software serão apresentadas com suas respectivas alterações. Para o desenvolvimento desta nova versão serão realizados estudos no campo da IHC (Interface Humano-Computador) considerando não somente o design de interfaces, mas também todos os aspectos relacionados à interação entre usuários e computadores. Serão estudados métodos 2D e 3D para uma melhor imersão, considerando questões como usabilidade e aplicabilidade. Um estudo sobre ferramentas de apoio ao desenvolvimento deste trabalho será feito com foco em programação para dispositivos móveis, já que o sistema deve estar

14 Capítulo 1. Introdução 13 disponível tanto para moradores quanto para os pesquisadores. Juntamente com o estudo realizado para melhor adequar o desenvolvimento do software deixando-o agradável ao usuário, serão estudados aspectos de jogos a serem incorporados a fim de torná-lo lúdico o bastante para que o respondente se sinta satisfeito ao estar praticando esta ação. Desde o princípio dos tempos a humanidade se familiariza com a idéia da utilização de jogos, e estes têm a capacidade de despertar curiosidade e distração, juntamente com a sensação de prazer que os desafios proporcionam ao jogador ao completarem um objetivo, principalmente se ele for posto em um contexto divertido onde a pessoa se sinta a vontade. 1.1 Estado da Arte Aspectos relacionados a jogos passaram a ser incorporados em atividades costumeiras, de forma a torná-las mais atraentes. Dentre os vários trabalhos que podem ser citados, estão o Starbucks (COMPANY, 2014), que pertence a uma companhia que trabalha com café e consiste em ganhar recompensas para cada produto que é consumido, e a Nike+ (NIKE, 2014) que permite aos usuários registrarem suas atividades e lançarem desafios às demais pessoas que também utilizam o aplicativo. Para os objetivos cumpridos são ganhos NikeFuel s, que são pontos que quando acumulados geram a obtenção de troféus entre outros. As formas como a interatividade poderá ocorrer no programa foram pesquisadas observando-se as interações disponíveis em diversos jogos e nas técnicas tradicionais de interação Homem-Computador com o objetivo de se atingir uma comunicação mais eficiente com o respondente. O conceito de gamificação (em inglês gamification) será usado, uma vez que corresponde ao uso de mecanismos de jogos orientados ao objetivo de resolver problemas práticos ou de despertar engajamento entre um público específico (VIANNA MAURÍ- CIO VIANNA; TANAKA, 2013). Ultimamente o conceito tem sido aplicado em diversas áreas como saúde, educação, políticas públicas, esportes entre outros, mostrando ser bastante produtivo também quando voltado para o campo da arquitetura e seus estudos, que é o que se trata a APO. O termo gamificação foi criado por Nick Pelling, programador de computadores e pesquisador, em 2002, mas ganhou popularidade com Jane McGonigal, famosa game designer norte-americana. Em 2011, o jogo Foldit, uma espécie de crowdsourcing(modelo de produção colaborativa que agrega diversas pessoas, de maneira presencial ou virtual, para resolver impasses, criar conteúdos ou desenvolversoluções), tinha como objetivo tentar compreender como determinada proteína poderia ser utilizada no combate da Aids. A atividade atraiu 46 mil participantes - a maior parte sem ligação nenhuma com a área médica -, que em 10 dias conseguiu elucidar um enigma que tomou

15 Capítulo 1. Introdução anos dos cientistas, que até então não haviam encontrado uma solução. Ou seja, esta técnica permite, através de aspectos lúdicos próprios de jogos, atrair um público maior em prol de um objetivo, que pode ser de natureza variável. Desenvolvido utilizando-se a plataforma Unity3D (TECHNOLOGIES, 2014), podemse citar sites como o Homestyler da Autodesk (AUTODESK, 2013), feito para profissionais do ramo da construção civil. O sistema permite que se monte plantas de uma maneira rápida, fácil e online, técnica que associada a parte do questionário destinada a unidade de moradia, ajuda a obter informações do apartamento ou da casa quando o questionário for aplicado via Internet. Outro site que possibilitou o levantamento de referências sobre interfaces gráficas foi o game ENERGUY (QUÉBEC, 2008) que tem como fundamento passar de forma divertida a consciência da economia de energia. No game o personagem deve ser guiado por uma casa onde vários objetos que se encontram ligados de forma errada, ou mesmo sendo utilizados de uma maneira com que gaste mais energia, a função do jogador é encontrar estes objetos e organizá-los de uma maneira com que seu consumo seja reduzido, em um tempo de dois minutos. Um detalhe importante que segue sua interface é a barra de progresso usada para manter o usuário informado do que foi e não foi feito por ele no decorrer do jogo. Um método bastante interessante e uma grande referência a ser tomada em se tratando de posicionamento e direcionamento. A Figura 1 ilustra o contexto citado. Figura 1 Tela final do jogo Energuy, mostrando ao usuário os objetos encontrados e organizados

16 Capítulo 1. Introdução Hipótese Um aplicativo para análise de pós-ocupação possui como prioridade o combate a resistência do público ao participar de um longo questionário, como também propiciar maior interatividade e praticidade aos respondentes. A forma como as informações são organizadas e consequentemente exibidas e digeridas pelo usuário exerce enorme influência na eficácia do cumprimento desta tarefa. Dessa forma, a hipótese desta pesquisa é a possibilidade de tornar a APO uma espécie de questionário dinâmico, utilizando aspectos lúdicos e divertidos. Uma interface digital ágil, simples, divertida e imersiva, implementada no formato de um jogo interativo, deve aumentar as chances de despertar maior interesse por parte das pessoas em responderem à pesquisa e consequentemente gerar resultados mais fiéis à realidade. 1.3 Objetivo O objetivo principal da presente proposta é desenvolver um software que, integrado a um dispositivo móvel, possa tornar o processo da Avaliação Pós-Ocupação mais eficiente, facilitando e tornando agradável o procedimento de responder às questões propostas, tornando-o um jogo eletrônico. De forma específica podem-se destacar: O estudo de ferramentas para dar suporte ao desenvolvimento do novo sistema, bem como ferramentas para auxiliar na criação do design e dos aspectos de interface em geral; O desenvolvimento de protótipos funcionais para o entendimento e para a definição dos requisitos do sistema e da interface; Discussão sobre integração de técnicas de Interface Homem-Computador no escopo da APO; Implementação do sistema de APO no formato de um jogo eletrônico. Incorporação de aspectos lúdicos que diminuam a resistência do usuário durante o processo de responder ao questionário. 1.4 Justificativa O processo tradicional de coleta de dados através de questionários em papel tem se revelado uma atividade enfadonha durante as pesquisas de Avaliação Pós-Ocupação. Isento de qualquer tecnologia, o ato de agrupar as informações adquiridas para que fossem estudadas posteriormente se torna massivo. No entanto mesmo o fato de passar todo o

17 Capítulo 1. Introdução 16 questionário para o meio digital não produziu o resultado esperado, já que o contexto continuava o mesmo, apenas visualizado em meio diferente. O tempo livre de cada pessoa vêm se tornando mínimo e em uma aplicação de APO no formato tradicional, a cada 50 pessoas convidadas a responder ao questionário, em média no máximo 10 pessoas participam. A necessidade de produzir juntamente às perguntas, algo que chamasse a atenção dos usuários e os divertissem parecia ser o contexto ideal a ser trabalhado. Com isso, o uso de técnicas desenvolvidas para jogos eletrônicos pode transformar o questionário tradicional numa atividade dinâmica e participativa. Outro aspecto que deve-se levar em conta é o problema de acessibilidade, podendo ser bastante minimizado com o uso de aplicativos para dispositivos móveis, que isentam o pesquisador de se locomover até suas fontes, como também evita que alguns de seus respondentes se sinta invadido de alguma forma, já que a coleta de dados é tradicionalmente feita na porta de suas residências. Uma pesquisa feita pelo Instituto de Pesquisas DataFolha (PESQUISAS, 2014) indica que 43 milhões de brasileiros utilizam a internet através de dispositivos móveis. Em função de todas estas informações apresentadas, introduz-se a idéia de transformar um questionário massante em algo mais dinâmico e lúdico, fazendo com que se torne divertida a nova forma de responder às perguntas, e possibilitando reduzir esforços de ambas as partes simplesmente pelo fato de o aplicativo poder ser baixado a qualquer momento por qualquer pessoa.

18 17 2 Metodologia Neste capítulo serão discutidos os métodos utilizados para que a pesquisa fosse direcionada de forma a alcançar os objetivos propostos. Diversos requisitos foram levantados, todos com propósitos diferentes e especificidades distintas, mas que ao se fundir permitiram atingir um resultado afinado com a hipótese deste projeto. A princípio a forma usual para a coleta de dados era um questionário impresso. Várias cópias do mesmo eram levadas ao local alvo de pesquisa, no caso algum prédio de apartamentos ou um bairro de moradia social. Era realizada a coleta de dados via uma dinâmica de perguntas e respostas, sendo que o pesquisador fazia a leitura das questões e era responsável por anotar as respostas fornecidas pelos moradores. O questionário padrão da APO contém em torno de 50 questões, que levam em média cerca de um minuto e meio para serem respondidas. Desta forma, a aplicação da APO apesar de possibilitar a coleta de dados valiosos, era lenta e trabalhosa. Para criar uma nova instância de aplicação da APO, que pudesse melhorar seu desempenho e torná-la uma atividade prazerosa, intencionou-se o desenvolvimento de uma interface digital que proporcionasse ao morador uma experiência de imersão em um ambiente que pudesse simular minimamente sua moradia. Neste ambiente seriam apresentadas as questões sobre sua forma de morar. Assim, a partir da definição da construção de uma interface digital sobre o morar e da necessidade da escolha de técnicas, metodologias e ferramentas de desenvolvimento de software, os procedimentos metodológicos para se alcançar os objetivos pretentidos neste trabalho foram: Definir as etapas do processo de elaboração da interface digital utilizando técnicas de engenharia de software aplicada a jogos e metodologias ágeis de desenvolvimento de software. O Scrum foi o método ágil utilizado para a definição das etapas da criação da interface digital. Estudar sobre a experiência do usuário em ambientes virtuais e realizar pesquisa bibliográfica e documental sobre o tema da Interface Homem-Computador (IHC). Pretende-se que o projeto da interface seja pensado de modo a combinar elementos visuais, auditivos e interativos que possibilitem uma forma de imersão no ambiente virtual. Este estudo tem também o objetivo de promover a construção de um ambiente que proporcione ao usuário satisfação e interesse, no qual as noções de navegabilidade estejam explícitas para que ele se sinta estimulado a permanecer no jogo. Pesquisar ferramentas que proporcionam portabilidade no desenvolvimento da in-

19 Capítulo 2. Metodologia 18 terface, uma vez que este projeto visa a implementação de uma aplicação que é suportada não apenas em dispositivos móveis, mas também em ambiente Web. Dentre elas, pretende-se explorar uma ferramenta bastante poderosa, que é a game engine Unity3D. Esta permite que os projetos desenvolvidos sejam compilados para diversas plataformas, notadamente Android e Web. Nesta engine é possível a criação de jogos tanto 2D quanto 3D o que gera liberdade de escolha da dimensão a ser utilizada. Seus scripts são produzidos a partir das seguintes linguagens de programação: C#, JavaScript ou Boo. Em prol da quantidade de informação documental relacionada às duas primeiras, estas terão destaque para o projeto. Figura 2 Logo da engine de games Unity3D Pesquisar ferramentas de design para a confecção dos objetos artísticos que compõem a interface digital. Uma vez que deve-se produzir o design nas dimensões já sugeridas, pretende-se neste trabalho identificar softwares que gerem objetos gráficos de boa qualidade e que proporcionem bons resultados. O Unity3D possibilita a importação de malhas 3D de alguns dos principais programas de modelagem, estes são: Blender (FOUNDATION, 2015), 3D Studio Max (AUTODESK, 2015a), Maya (AU- TODESK, 2015b) e Cinema4D (MAXON, 2015). Foi dada maior importância aos três primeiros já que são bastante conhecidos no mercado por seu excelente desempenho, sendo que o primeiro tem a vantagem de ser um software livre, ou de código aberto, não sendo necessária a aquisição de nenhum tipo de licença para operá-lo. Também pretende-se pesquisar ferramentas que trabalham basicamente com 2D e são bastante usadas para fins de modelagem gráfica, como: Gimp (GIMP, 2015), Photoshop (ADOBE, 2015d), Illustrator (ADOBE, 2015b). Sendo que como o Blender, o Gimp também possui código aberto. Desenvolvimento de um protótipo da interface interativa de APO usando as ferramentas, técnicas e metolodogias supracitadas, possibilitando um vislumbre para um projeto mais completo futuramente. O protótipo servirá como uma espécie de framework para desenvolvimentos posteriores, contendo os principais fatores que devem margear o game.

20 19 3 Referencial Teórico Ao final do projeto pretende-se obter não apenas um questionário, mas também um protótipo interativo disponível para a comunidade. Neste caminho, a fundamentação deste projeto é voltada para técnicas de jogos em dispositivos móveis e suas metodologias de desenvolvimento, considerando as questões de Interface Humano-Computador. Este capítulo trata dos aspectos teóricos fundamentais do projeto e das ferramentas de modelagem de objetos gráficos utilizadas para a confecção dos elementos pertencentes ao software. 3.1 Engenharia de software aplicada a jogos Diferentemente da engenharia de software tradicional, a engenharia de software aplicada a jogos digitais deve englobar o fator multidisciplinaridade, envolvendo não apenas a lógica computacional necessária, como também aspectos de áudio, imagens e vídeos, que são complementos indispensáveis. Para tanto, o gerenciamento destas diversas áreas pode ser caótico se não forem empregadas as técnicas corretas para que haja a harmonia entre elas. Junto a isto deve-se levar em consideração a cultura atual de grupos envolvidos em desenvolvimento jogos digitais e buscar referência em metodologias que proporcionam o impulsionamento da produção e o gerenciamento de uma equipe multidisciplinar. O processo de desenvolvimento de jogos digitais incorpora uma etapa de projeto do jogo em adição às etapas tradicionais de análise e projeto do software e seu posterior desenvolvimento. O projeto do jogo é considerado uma fase de pré-produção que descreve o jogo em detalhes, delineando a estória, a mecânica das ações do jogo, a descrição dos personagens, o conceito de arte, análise de mercado e de viabilidade, entre outras características. A equipe da área de Design é responsável pela elicitação dos requisitos a partir do cliente e de possíveis usuários e por definir a estrutura do aplicativo e suas características, gerando os artefatos da pré-produção. Em seguida estes artefatos são convertidos numa especificação tradicional de software. A Figura 3.1 ilustra a interação entre os atores do processo de produção deste tipo de software. O processo de desenvolvimento de aplicativos utilizando técnicas de jogos eletrônicos envolve concepção, produção e acabamento. Esse processo é dividido em três fases nas quais atuam os diversos profissionais envolvidos: 1. Pré-Produção

21 Capítulo 3. Referencial Teórico 20 Figura 3 Coleta e mediação de requisitos feita pelos projetistas de jogo a) Design de Ambiente e Jogabilidade Nesta etapa é apresentada à equipe a plataforma para a qual o jogo será portado e possíveis limitações que deverão ser levadas em conta. Esta etapa define o que deve-se desenvolver para que o jogo fique o mais confortável possível para o usuário. b) Roteiro e Conteúdo O que acontece durante o jogo e como serão apresentadas as informações e desafios, são tópicos discutidos nesta etapa. Pode-se ter a apresentação de um protagonista que fará o papel do jogador dentro do ambiente digital e de como suas ações serão refletidas no jogo. 2. Produção a) Desenvolvimento de Material Artístico Após a contrução das idéias durante a pré-produção, a equipe gráfica inicia a construção do cenário digital, como também dos personagens, itens e menus. b) Desenvolvimento de Software Feita após ou em paralelo à contrução do material artístico, nesta etapa é colocada em prática a lógica de como os objetos interagem entre si e com os usuários. 3. Pós-Produção a) Testes O software é testado funcionalmente e diretamente, verificam-se possíveis erros e desconfortos com o intuito de serem corrigidos antes da finalização do projeto. São feitos testes alfa, realizados pela própria equipe desenvolvedora como também testes beta realizados com um público alvo. b) Garantia de Qualidade Os testes refinam o jogo e criam melhores chances de se atingir o que foi idealizado, podendo agradar melhor o usuário da aplicação e proporcionando uma taxa de erros menor.

22 Capítulo 3. Referencial Teórico Uso de Metodologias Ágeis no Desenvolvimento de Jogos Os princípios propostos em Metodologias Ágeis definem uma nova maneira de desenvolver e gerenciar software, tendo como base um conjunto de valores compatíveis, baseados na confiança e respeito pela equipe de trabalho e promovendo modelos organizacionais simplificados e centrados nas pessoas e na colaboração entre elas (PRIKLAD- NICKI; WILLI; MILANI, 2014). A grande diferença entre Métodos Ágeis dos demais é que estes possuem um foco maior no cliente do que no processo. O termo Métodos Ágeis tornou-se popular em 2001 quando 17 especialistas em desenvolvimento de software representando metodologias já existentes (XP, Scrum entre outras) estabeleceram princípios comuns a todas elas. Assim surgiu a Aliança Ágil e o estabelecimento do Manifesto Ágil. O Manifesto Ágil não faz discriminação às diferentes metodologias, porém coloca em prioridade a relação entre desenvolvedor-cliente, sendo que durante o processo de construção do software o cliente estará presente em todas as etapas, reduzindo bastante o tempo de resposta para dúvidas que surgirão naturalmente de ambas as partes. Entregas parciais do produto são feitas pela equipe desenvolvedora sempre colocando todos cientes do que ocorre. Reuniões, documentações e negociações de contrato, características bastante marcantes em metodologias mais tradicionais, não deixam de ter sua relevância porém são deixadas em segundo plano. Duas propostas bastante adequadas ao que esta sendo proposto neste trabalho são os métodos XP (extreme Programming) e Scrum, ambas metodologias ágeis para gestão dinâmica de projetos. Considerando-se que este projeto possui um tempo curto e demanda uma quantidade de informações razoáveis a serem apresentadas de forma simples e interativa para o usuário, optou-se pela metodologia Scrum, que é orientada a projetos nos quais diversas capacitações interdisciplinares necessitam trabalhar juntas a fim de alcançar um objetivo comum. O método XP possui vários conceitos similares ao Scrum, como a relação próxima entre cliente e desenvolvedor, programação em pares e entregas parceladas do projeto, no entanto, o software que será implementado trabalhará com prazos e com tarefas com mais prioridades que outras, além de contar com um elenco de produção multidisciplinar, ou seja, não apenas composto por conhecedores de computação, como também designers, arquitetos e artistas. Logo métodos como backlog e sprint e etapas de Pré-Produção, Produção e Pós-Produção, divisões necessárias para tal desenvolvimento, são definições pertencentes ao Scrum e bastante satisfátórias quando incorporadas à este projeto. Segundo Pressman (2014) os princípios do Scrum são consistentes do manifesto ágil e são usados para orientar as atividades de desenvolvimento dentro de um processo que incorpora as seguintes atividades estruturais: requisitos, análise, projeto, evolução e

23 Capítulo 3. Referencial Teórico 22 entrega. A cada etapa do projeto geral são geradas tarefas chamadas de sprint, o tempo para cada uma destas atividades varia de acordo com sua complexidade. Atividades ainda não produzidas são organizadas em um registro pendente de trabalhos nomeado backlog. Estas atividades são colocadas em ordem de prioridade de acordo com a demanda do cliente e atualizadas pelo gerente do projeto. Pode-se observar na Figura 4 como se dá o processo completo. O método Scrum (nome de uma atividade que ocorre durante o jogo esportivo rugby) foi desenvolvido por Jeff Sutherland e sua equipe de desenvolvimento nos anos 90 e mais tarde aprimorado por Schwaber e Beedle. Figura 4 Fluxo de processo Scrum (PRESSMAN, 2014) As reuniões Scrum são realizadas diariamente e em um prazo de aproximadamente 15 minutos, e três questões chaves devem surgir: O que foi realizado desde a última reunião da equipe? Quais obstáculos a equipe está encontrando? Quais as metas para a próxima reunião? A reunião é conduzida pelo líder, chamado Scrum Master, que têm o trabalho de avaliar as respostas das questões. Outros aspectos positivos resultantes das reuniões é a transmissão do conhecimento entre os membros, a solução de possíveis problemas e uma auto-organização da equipe. A produção de Demos é de fundamental importância, pois o desenvolvedor mostra os incrementos ao cliente com o intuito de serem avaliados. Ressaltando que a demo não necessita estar totalmente pronta mas apresentada no tempo estipulado.

24 Capítulo 3. Referencial Teórico Interface Humano-Computador De acordo com Hewett (2009) a definição de IHC seria, Projeto (design), avaliação e implementação de sistemas computacionais interativos para uso humano, juntamente com os fenômenos associados a este uso, ou seja é preciso ter conhecimento de técnicas que envolvam a interface do software em questão e a interação dela com o usuário, é preciso definir métodos, modelos e diretrizes. E em se tratando de um jogo alguns padrões de conforto devem ser deixados de lado. Os atos de conhecer, competir, desafiar, instigar e criar por mais que sejam instintivos são alguns fatores que normalmente causam certa ansiedade ao ser-humano que, por natureza, apresenta alguma resistência em enfrentar novos desafios. Para isso, o estudo das técnicas de Interface-Humano Computador tradicionais auxiliam na adaptação do software ao usuário para que ele se sinta confortável ao utilizá-lo. E por que tradicionais? Será que estes incômodos são de fato evitados? Uma pessoa quando se dispõe a participar de um jogo ela se prontifica a experimentar todos estes sentimentos por livre e espontânea vontade, ela está disposta a conhecer, competir, desafiar e ser desafiada, e a cometer erros para depois ser acertiva. Nielsen e Mack (1994) mencionaram cinco princípios de usabilidade que um sistema deve ser detentor, que são: aprendizado eficiência memorização prevenção de erros satisfação Sobre isso, Barr (2008) mostra em sua tese que dos cinco itens citados, apenas um se aplica ao modelo IHC para jogos, que seria a satisfação. Os demais são aplicados de maneiras diferentes. Um bom jogo faz com que seus praticantes se esforcem para alcançar seus objetivos, faz com que um caminho tenha que ser percorrido mais de uma vez, ou propõe soluções para quebra-cabeças. O jogo não deve ser fácil mas sim propor metas a serem alcançadas recompensando o árduo esforço do jogador. Jogos são uma quebra de paradigmas em se tratando de IHC, são atividades que propõem competição, novos conhecimentos, contam histórias onde o usuário se coloca no papel de personagem principal, promove a criatividade e o senso de estratégia de uma maneira natural, aguça a curiosidade quando o jogador deve descobrir o que irá acontecer depois de um determinado obstáculo. Em jogos digitais, o jogador é convidado a imergir em um ambiente virtual, fazendo com que ocorra uma fuga da realidade para um universo onde as escolhas feitas por ele, enquanto personagem, não surtirão efeito em sua vida real, mas sim em sua vida fictícia. Esta prática proporciona uma sensação que desbancará todos

25 Capítulo 3. Referencial Teórico 24 os desconfortos dos quais a IHC se preocupa, o sentimento de liberdade se torna maior que qualquer outro. No entanto, isso não isenta os games das questões estudadas na IHC, pelo contrário, o foco dos conceitos apenas estão direcionados a aspectos diferentes dos usuais, mas ainda muito importantes. O jogo apesar de desafiador ainda precisa se preocupar em ser chamativo e propor dinâmicas agradáveis. Não significa que obstáculos difíceis de serem superados devam ter também seus acessos trabalhosos. O teor do jogo deve proporcionar complexidade suficiente para entreter o jogador, porém a interface dos botões e a disposição das informações na tela, tanto para diálogos e escolhas de itens, são melhor aceitas quando mais intuitivas e fáceis aos olhos do usuário. Questões importantes em IHC como metáforas, affordances e menus são técnicas primordiais. Metáforas É evidente que a maioria dos jogadores não possui o costume de realizar alguma leitura durante o decorrer do jogo. Textos muito grandes acabam se tornando desgastantes e explicações podem ser ainda mais tediosas. Por isso aplicando-se um estudo de metáforas, com foco no público-alvo desejado, aspectos que antes seriam de difícil compreensão, simplificam a interface e a deixam com um aspecto mais limpo referente a ícones e botões, aumentando as chances de se obter uma compreensão imediata ou semi-imediata sobre as ações daquele objeto, antes mesmo do seu acesso. Segundo Dix Janet E. Finlay e Beale (2004), metáforas são bastante utilizadas para ensinar com sucesso novos conceitos em termos anteriormente compreendidos. Affordance São estilos de interface gráfica que tentam imitar aspectos do mundo real no virtual, acreditando que o ser-humano pode identificar objetos e interagir com os mesmos apenas pela similaridade sugestiva. Um botão vermelho com sua perspectiva saltando para frente, simularia um botão que possivelmente reagirá ao ser pressionado ou uma alavanca que deva ser movida para alguma direção. Geralmente affordances são bastante inspirados na cultura da qual a aplicação é destinada. Menus Se baseiam em um conjunto de opções disponíveis para o usuário, sendo estas menos comumente acessadas, agrupadas de forma que tenham algum objetivo em comum. São exibidos na tela e podem ser expandidos pelo toque sobre os mesmos. Normalmente o ícone que dá nome à um menu fornece uma pista sobre o que o usuário encontrará ao acessá-lo. Os itens supracitados são especificações ergonômicas que facilitam a interação entre homem-computador por meio do estudo dos componentes físicos que compõem a

26 Capítulo 3. Referencial Teórico 25 interface. Outro tipo de aspecto ergonômico que deve ser observado é a movimentação dos personagens e demais objetos com os quais o jogador entrará em contato. Uma movimentação inadequada realizada ao serem controlados geram certa estranheza ao usuário. O erro pode vir tanto da equipe gráfica ao entregar animações mal produzidas, quanto da equipe lógica ao implementar alguma movimentação que não seja adequada. Um exemplo seria o jogo GTA 2, produzido pela Rockstar Games (GAMES, 1999), que possui uma visão de topo e ao controlar o carro para frente os comandos para virar à esquerda e direita correspondiam às teclas A e D, porém se o carro tomasse o sentido contrário vindo para trás, então virá-lo para a esquerda seria D e para direita A, invertendo-se a ordem das direções e confundindo os jogadores. A Figura 5 ilustra esta situação. Figura 5 Telas do jogo GTA II, desenvolvido pela Rockstar Games. A figura ilustra a confusão de direções que o jogador é exposto ao se mover para cima e para baixo 3.4 Unity Por questões práticas e ágeis em um projeto de um jogo a utilização por parte da equipe de uma engine, ou motor é um fator de grande relevância nos meios de produção. Sua principal função será unir os diversos itens que compõem um jogo em apenas um local e ter como finalidade um produto com o qual o usuário possa interagir. Segundo Almeida (2006), a engine do jogo é a parte principal do software. Ela é responsável por gerenciar recursos (sons, músicas, imagens, modelos, animações, textos), prover elementos fundamentais do jogo (mecanismos de física, de inteligência artificial, de interação com cenários e objetos) e abstrair a complexidade destes elementos para o desenvolvedor da lógica do jogo. Uma engine funciona como uma camada de abstração dos recursos fundamentais de um jogo. A engine a ser utilizada neste projeto será a Unity 3D, que se mostrou bastante promissora ao apresentar vários componentes que auxiliam na montagem do software do jogo, como colisões, corpos rígidos, físicas de terreno, GUI textures utilizadas nas montagens de menus, e uma API para desenvolvimento bastante completa. Possui três linguagens de programação Boo, C# e a UnityScript (mais conhecida como JavaScript para o Unity segundo a própria documentação do software (ALEKSANDR, 2014)). As

27 Capítulo 3. Referencial Teórico 26 linguagens mais utilizadas para os desenvolvimentos são C# e UnityScript, conforme Figura 6. Figura 6 Gráfico da análise do editor do Unity sobre a frequência de utilização das linguagens Boo, C# e UnityScript (ALEKSANDR, 2014) C# e UnityScript possuem diferenças, no entanto, algumas vezes é mais vantajoso o uso de uma ou outra e contam com uma vasta documentação aplicada ao que será utilizado neste projeto. Outro aspecto favorável ao Unity 3D seria sua interface amigável que proporciona suas funcionalidades de uma forma fácil e intuitiva totalmente customizável, onde uma certa janela ou painel pode estar situado em qualquer local variando da vontade de cada utilizador. A engine ainda permite a compilação do projeto final para várias plataformas diferentes abrangendo sistemas operacionais como IOS, Android, Windows Phone, Linux, Windows, Playstation3 e 4, Xbox360 e One entre diversos outros, totalizando 22. Uma vez que se codifique o software apenas uma vez e este possa ser gerado para diversas plataformas, sem a necessidade de mudanças na codificação, torna-se bastante vantajoso o uso deste motor de jogos Interface e funcionalidades da Unity 3D A interface customizável da engine é um fator que agrada. Os principais painéis que auxiliam o desenvolvedor na produção do game podem ser realocados em qualquer localização dentro dos limites da janela do programa, permitindo que alguns aspectos possam ser melhor visualizados hora sim outra não, dependendo da etapa em que se encontra o desenvolvimento. Dentro deste ambiente destacam-se os painéis de: Console Retorna ao desenvolvedor o resultado dos Scripts ao serem compilados e demais informações sobre a parte lógica. Game Painel que mostra o game em si como resultado final ou parcial.

28 Capítulo 3. Referencial Teórico 27 Hierarquia São apresentados os componentes contidos na cena (scene) e suas hierarquias um em função do outro. Inspector Painel onde são mostradas as composições de um objeto (ou componente) na cena, como posição, escala e rotação, possíveis efeitos de física, e scripts associados a estes. Project Mostra a pasta raiz do projeto onde estarão todos os objetos que farão parte do game, como scripts, malhas em 3D, texturas e materiais. Scene É o principal painel de edição onde os objetos são organizados e montados. Na Figura 7 pode-se observar melhor cada painel e reforçar melhor o que foi dito anteriormente. Figura 7 Tela da engine Unity em fase de produção do projeto Como Você Mora especificamente na cena de customização do personagem 3.5 Ferramentas de modelagem, animação e texturização Como já mencionado na Seção 3.1, o desenvolvimento de um game possui como essência o fator da multidisciplinaridade. Em consequência, este trabalho aborda também programas que auxiliam na produção da parte gráfica 3D e sua respectiva texturização, tratando de metodologias para suas concepções e técnicas para a redução do tamanho dos componentes. Considerando que o jogo terá como alvo a plataforma mobile, é recomendada a construção de objetos leves priorizando-se a performance.

29 Capítulo 3. Referencial Teórico Blender A emersão cada vez maior da tecnologia 3D na época atual deve-se principalmente às grandes produções cinematográficas e aos games que se utilizam cada vez mais esta tecnologia. Tais produções são utilizadas para entretenimento e conquistaram o gosto da grande maioria das pessoas. Em consequência, tornaram-se bastante evidentes as ferramentas que proporcionaram as criações de objetos em 3D. Os softwares de modelagem 3D são inúmeros, alguns com mais prestígio que outros. Nomes como 3D Studio Max (AUTODESK, 2015a), Maya (AUTODESK, 2015b), SketchUp (GOOGLE, 2015), Cinema4D (MAXON, 2015), todos com grandes possibilidades e peculiaridades. Neste projeto será adotado um software com iniciativa opensource, que se equipara aos citados anteriormente, denominado Blender ou Blender 3D (FOUNDATION, 2015), que deu seus primeiros passos em 1995 com holandês Ton Roosendaal co-fundador do estudio de animação NeoGeo e mais tarde fundador da NaN (Not a Number). Depois de passar por altos e baixos foi acolhido pela causa OpenSource e veio ao mundo em 13 de outubro de 2002 sobre os termos da GNU General Public License. Desde então o software vem evoluindo cada vez mais, recebendo contribuições de vários voluntários que se unem à causa da Blender Foundation. Hoje é um software bastante robusto fornecendo técnicas para modelagem, renderização, animação. Pode ser usada também como uma engine de jogos e está a altura de seus concorrentes proprietários Produção do Personagem A criação de um personagem no Blender ou em qualquer outro software necessita passar por processos que envolvam a prototipagem do mesmo, desde os primeiros rabiscos em uma folha de papel até sua produção final visando seu encaixe no jogo. Uma técnica bastante utilizada entre Designers de personagens define que o melhor posicionamento que um corpo bípede deve ter para sua modelagem em um software 3D é em forma de T como mostra a Figura 8, isto possibilitará uma distorção mais real da malha quando o personagem passar pelo processo de animação. As etapas básicas para a produção de um personagem seguem uma sequência que pode ser definida pelas atividades: A construção do desenho base do personagem nas visões de frente e lateral. Estes desenhos ficam ao fundo do editor e servem como referência para a modelagem 3D do mesmo. Este esboço é comumente chamado de model sheet. A modelagem em si sendo um espelho do model sheet deve levar em conta todos os aspectos de profundidade e perspectiva. Uma observação bastante interessante para este item é a economia em polígonos na modelagem do personagem. Esta economia é recomendada para games direcionados para plataformas mobile ou mesmo

30 Capítulo 3. Referencial Teórico 29 Figura 8 Personagem feito para o protótipo do jogo Como você mora na posição T ideal para futura animação para plataformas que exigem uma certa eficiência de software pelo hardware e que possuem uma agilidade de processamento inferior. A modelagem do personagem se dá através de polígonos que definem as formas que se tornam a parte base do personagem. Após a modelagem o personagem se encontra com uma única cor, semelhante a uma estátua de mármore, neste momento será incorporado cores ao personagem para que fique de acordo com a proposta do jogo. A subseção irá se aprofundar nos detalhes desta parte. Com o personagem pronto visualmente, entra-se no processo de incorporar ossos à malha. Como qualquer animal, modelos em terceira dimensão também necessitam receber uma estrutura óssea composta de várias juntas, cada osso possui uma certa influência em uma dada área do modelo ao serem associados, fazendo com que o controle das articulações apenas flexione a malha correspondente. Feitos os movimentos, a próxima etapa será as animações da qual o personagem fará uso durante o jogo. Ações como correr, andar, interagir com o usuário, são produzidas no blender e incorporadas ao Unity mais tarde para que possam ser utilizadas nos momentos certos Produção do cenário O cenário possui componentes construídos um a um separadamente e só agrupados mais tarde na engine. A maquete digital possui oito localidades com as quais o avatar poderá interagir, cada uma contendo uma parte do questionário associado. O ce-

31 Capítulo 3. Referencial Teórico 30 nário contará com um hospital, um condomínio de prédios, uma área para lazer parecida com uma praça, um conjundo com casas, uma igreja, um shopping, um bloco central de prédios fazendo menção ao centro da cidade e uma árvore anciã, que fará contato com o personagem para tratar de assuntos sobre consciência ecológica Photoshop O software Adobe Photoshop CS4 foi utilizado na pintura dos mapeamentos gerados pelo Blender referentes ao personagem, pelo fato de conter todo o aparato necessário para realizar um trabalho rápido e prático, contando com ferramentas de seleção, contagotas, telas paralelizadas em uma mesma janela e camadas. Devido à organização das camadas, a correção de erros é quase instantanea, poupando tempo para os demais procedimentos. Figura 9 Tela do Programa Adobe Photoshop CS4 apresentando diversar janelas abertas em paralelo, referentes a pintura do personagem, da igreja e uma paleta de cores

32 31 4 Trabalhos Correlatos Neste capítulo serão abordados os demais trabalhos que serão inspiração para produção deste projeto. Lembrando sempre que a proposta deste trabalho, da forma que será implementado faz com que ele não possua antecedentes com os quais seja possível fazer um espelhamento, porém o desenvolvimento do jogo neste trabalho fará uso de várias técnicas que podem ser encontradas em diferentes softwares. Um dos games utilizados como referência neste trabalho e para impulsionar este projeto é o já citado ENERGUY (QUÉBEC, 2008) que vem com a proposta de ensinar as pessoas a se concientizarem com a causa da economia de energia. A dinâmica é arrastar o personagem pela casa e descobrir 20 situações que o ajudarão a poupar energia, tudo isso em um tempo de dois minutos. De uma forma lúdica e ilustrativa o jogador é desafiado e toma conhecimento acerca da proposta do jogo. Outro game que também já foi citado neste artigo, e que também foi utilizado como referência é o HOMESTYLER da AUTODESK (AUTODESK, 2013). Este game utiliza a mesma engine que este projeto, a Unity (TECHNOLOGIES, 2014). Com isso espera-se que esta referência possa abrir possibilidades para que seja possível conhecer melhor as limitações do jogo aqui proposto em substituição a um questionário tabular, e as vantagens de estar trabalhando a Unity. Outra ferramenta concorrente à Unity3D, o Adobe Flash Pro (ADOBE, 2015c), carrega o título de software mais popular, quando se trata de jogos para web. Existem vários sites destinados a disponilizar centenas de jogos produzidos com o uso desta ferramenta, dando total suporte a trabalhos com perspectiva 2D. O software disponibiliza uma interface bastante prática e recursos suficientes para a produção de games simples, e a partir da versão cinco, consegue-se exportar seus resultados para plataforma web e mobile. No entanto com o passar do temmpo essa ferramenta foi se desgastando e houve redução no número de usuários. A Unity 3D além de dar total suporte a jogos 2D e 3D consegue portar seus trabalhos para diversas plataformas além da web e da mobile. O Google, atualmente é o site mais famoso para buscas em geral, possui uma ferramenta chamada Google Trend, que constrói um gráfico de interesse com base nas pesquisas realizadas nele. Foram feitas duas pesquisas e ambas mostram que o software da Adobe vem perdendo poder, dando lugar às novas tecnologias, e podem ser verificadas nas Figuras 10 e 11.

33 Capítulo 4. Trabalhos Correlatos 32 Figura 10 Curva de interesse entre os anos de 2005 a A linha em azul trata da linguagem de programação C# usada na Unity, e a linha vermelha refere-se à linguagem usada no Adobe Flash, ActionScript. Figura 11 Curva de interesse entre os anos de 2005 a A linha em azul trata de pesquisa pela engine Unity, e linha vermelha refere-se ao software Adobe Flash.

34 33 5 Avaliação Pós-Ocupação Avaliação Pós-Ocupação é uma forma de pesquisa rigorosa e sistemática para medir a satisfação de moradores, com relação aos aspectos funcionais e comportamentais dos espaços habitacionais, algum tempo após sua construção e ocupação. A partir do ponto de vista de especialistas como arquitetos, engenheiros, designers, psicólogos e do próprio proprietário, a APO busca obter diagnósticos e informações confiáveis sobre o desempenho e comportamento do ambiente avaliado no decorrer do seu uso. Assim, em projetos futuros, deve ser possível utilizar as informações com objetivo de criar projetos mais eficientes tanto no custo quanto na utilidade. O desempenho dos edifícios é avaliado, diariamente, de forma inconsciente e não explícita. Entre as avaliações estão isolamento acústico, temperatura do recinto, qualidade de iluminação, mobiliário, acabamento e até tempo de espera pelo elevador. Em um mercado cada vez mais competitivo, a meta do fabricante ou do projetista passa a ser a criação de produtos com desempenhos que atendam às expectativas de mercado, com preços acessíveis e que apresentem o mínimo possível de defeitos. Neste sentido, a APO pretende analisar a performance dos edifícios, através da comparação sistematizada e rigorosa dos resultados, segundo critérios de desempenho pré-estabelecidos. As diferenças evidenciadas, possibilitam a avaliação. A busca pelo aprimoramento metodológico a partir do uso de equipamentos portáveis se deu principalmente a partir de uma investigação sobre os principais avanços metodológicos na área da APO, na qual se identificou que a grande maioria das pesquisas realizadas no Brasil se restringe a utilização de recursos tradicionais na aplicação das técnicas como o questionário em papel. Mesmo quando pesquisas se utilizam de softwares específicos para aplicação de surveys, podendo ou não ser em ambiente Web, possuem baixo nível de interação com o usuário. Frequentemente o uso de tecnologia se restringe ao uso de equipamentos eletrônicos como câmeras, gravadores e medidores de desempenho, utilizados na complementação da aplicação das técnicas e/ou no levantamento de dados dos estudos de caso. Neste contexto, várias demandas se configuraram como questões indutoras para o desenvolvimento da pesquisa: Ampliação da eficiência e da confiabilidade dos resultados da avaliação obtidos por métodos quantitativos. Busca-se, nesta pesquisa, o conjunto de métodos avaliativos do espaço habitacional que forneça resultados cada vez mais fiéis à realidade. Possibilidade de maior interação entre o pesquisador e o morador na avaliação, explorando-se formas de interatividade entre recursos gráficos e moradores.

35 Capítulo 5. Avaliação Pós-Ocupação 34 Redução dos custos da avaliação, considerando-se a diminuição do custo em papel, a eliminação de possíveis dúvidas de preenchimento e a redução no tempo da pesquisa. Ampliação da eficiência da tabulação dos resultados da avaliação através da utilização de programas auxiliares para a análise e formatação dos dados. Capacidade gráfica e multimídia do meio digital potencializando as interações através da exploração de recursos gráficos na pesquisa avaliativa dos espaços habitacionais. Utilização da tecnologia não somente como equipamento, mas como parte funcional e integral da avaliação, visando aproximar usuários do processo de criação da interface. Capacidade da avaliação se tornar educativa reforçando novas agendas em relação a aplicação de APO como processo e não somente como produto (COLE, 2005). Segundo, Coates, Arayici e Ozturk (2012), a tecnologia vem ampliando sua área de influência, e é normal que abranja também o espaço de moradia. Além disso, a preocupação com a forma de morar vem se acentuando bastante graças a demandas projetuais e a questões de sustentabilidade do ambiente. Reunindo essas duas problemáticas vê-se que a tecnologia digital pode ajudar o desenvolvimento da APO, podendo abranger mais tópicos e assim possibilitar uma avaliação mais completa e eficiente. A proposta de construção da interface buscou satisfazer a ideia de amigabilidade, que pode ser entendida por: (i) usabilidade: facilidade de uso (esforço físico e cognitivo) e de aprendizado das operações presentes no sistema (sem detrimento da eficiência e produtividade) e grau de satisfação do usuário durante o uso; (ii) aplicabilidade: utilidade do sistema na resolução de problemas variados e específicos, resultando numa aplicação de software que deve servir à especialidade do usuário; (iii) comunicabilidade: como o sistema comunica para o usuário, de modo eficiente, os princípios e as intenções de interações que nortearam seu design. A meta da comunicabilidade é habilitar o usuário a entender as premissas, intenções e decisões tomadas pelo designer durante a elaboração da interface. Uma aplicação que leva o usuário a conhecer melhor a lógica do designer pode propiciar-lhe um uso mais criativo, eficaz e produtivo (PREECE, ROGERS e SHARP, 2005). 5.1 Base de Dados da Avaliação Pós-Ocupação Essencialmente, a base de dados de uma Avaliação Pós-Ocupação são as perguntas que a constituem, as quais podem ser dos seguintes tipos de entrada de resposta:

36 Capítulo 5. Avaliação Pós-Ocupação 35 Escolha Única: o respondente tem a possibilidade de escolher uma opção de resposta dentre várias listadas; Múltipla Escolha: o respondente pode escolher quantas opções desejar de uma lista preestabelecida das mesmas; Intervalo Numérico: o respondente escolhe um valor numérico pertencente a um intervalo inicial e final preestabelecido pelo avaliador; Texto Aberto: o respondente tem a liberdade de escrever o texto que desejar como resposta da pergunta. Além de diferentes tipos de resposta, uma pergunta pode estar associada aos seguintes tipos de entidades: Conceito, Atributo e Cômodo. Tais entidades são previamente criadas pelo pesquisador para que no momento da criação das perguntas, associações com qualquer uma das três entidades possa ser feita. Isto é, uma pergunta pode ser associada a nenhum ou vários Conceitos, Atributos e Cômodos, portanto uma relação zero ou muitos com cada entidade. A Figura 12 ilustra o relacionamento entre as entidades. Figura 12 Classificação de palavras-chave em grupos de afinidades nas técnicas da APO Uma pergunta além de poder estar associada com Conceitos, Atributos e Cômodos também possui relação com outras entidades. Qualificador é a opção de resposta que uma pergunta pode ter caso a mesma tenha resposta do tipo escolha única, múltipla escolha ou intervalo numérico. Além dessas associações, temos a associação de uma pergunta com uma Categoria, que pode conter várias outras perguntas. Um nível acima da Categoria temos as Técnicas que podem conter várias Categorias. Por fim, temos uma APO que é formada por um conjunto de técnicas. A Figura 13 apresenta o diagrama de classes para estruturar o questionário e possibilitar o armazenamento das respostas das aplicações de APOs. Resumidamente, o pesquisador deverá criar uma APO, depois as técnicas pertencentes à mesma, cada uma com suas categorias e por último, perguntas que compõem as categorias. Por fim, as respostas das perguntas devem ser identificadas unicamente pelo

37 Capítulo 5. Avaliação Pós-Ocupação 36 Figura 13 Diagrama de classes da camada de modelo conjunto de identificadores de uma pergunta, cômodo, conceito, atributo e morador. Portanto, uma mesma pergunta pode ter diversas respostas de um mesmo morador, contanto que essa pergunta esteja associada à conceitos, cômodos e atributos. Uma das questões da APO está apresentada na Tabela 1. Indique sua satisfação em relação aos aspectos gerais de seu edifício: Qualidade da construção geral Aparência geral Limpeza e conservação dos espaços Nível de convivência entre os vizinhos Ótima Boa Regular Ruim Péssima Tabela 1 Exemplo de questão da APO apresentada aos moradores

38 37 6 Desenvolvimento A primeira versão da APO Digital concentrou seu potencial na redução do esforço do pesquisador e do pesquisado, reduzindo o tempo da pesquisa e da coleta de dados, apenas pelo fato das perguntas estarem contidas em um ambiente digital por meio de um tablet. O ato de respondê-las tornou-se mais ágil, obtendo êxito ao substituir a versão do questionário que era impresso em simples folhas sulfites e preenchidas a caneta. A versão foi concluída com sucesso e sua aplicação realmente provou ser mais vantajosa que a anterior. No entanto, notou-se que as pessoas estão mais reservadas e relutantes ao serem submetidas a este tipo de situação, o que pode ser bastante prejudicial aos pesquisadores de arquitetura que dependem das respostas desta população, para estimarem problemas e buscarem novas soluções. No intuito de evolução da pesquisa foi proposta a produção não só de um questionário em um ambiente digital, mas algo que trouxesse certo prazer durante o processo da APO, proporcionando satisfação ao respondente e que permitisse liberdade de responder ao questionário sem ser guiado por um pesquisador. Este projeto surgiu como um fruto destas demandas que ansiavam por uma solução. Para isso bastou um olhar mais detalhado em direção ao público alvo. Graças ao contexto evolutivo tecnológico várias pessoas dispensaram o uso de jornais, revistas, computadores, video-games pelo simples fato de todos estes estarem contidos em aparelhos celulares, sem que a prática da leitura ou do entretenimento se perca. O aumento da assessibilidade a este tipo de dispositivo móvel e os meios que eles disponibilizam para divulgação foram as soluções para que a pesquisa chegasse aos respondentes de forma fácil por meio de um aplicativo que pudesse ser baixado a qualquer momento por qualquer um. No entanto, ainda havia a dúvida de como fazer um respondente se sentir satisfeito ao preencher um questionário. Jogos são as formas mais antigas e satisfatórias encontradas na história da humanidade que estimula a continuidade de sua prática pelo simples fato de serem divertidos e lúdicos. Com isso consolidou-se a base de onde partiria toda a produção desta pesquisa, que busca não só estatísticas ao obter respostas mas também tornar mais satisfatório o ato de respondê-las. O desenvolvimento deste projeto é constituído por etapas que serão descritas em detalhes neste capítulo, mostrando conhecimentos adquiridos e dificuldades superadas no decorrer da construção deste protótipo para Avaliações de Pós-Ocupação. Como a proposta é torná-lo não apenas um simples questionário mas um game, vários aspectos que serão citados possuem técnicas utilizadas na produção da maioria dos jogos em terceira dimensão, abordando questões de eficiência e economia de recursos, consequências da escolha da plataforma. Para que a identificação das etapas seja facilitada, elas serão nomeadas de acordo com suas principais ações ou técnicas que mais se destacaram durante

39 Capítulo 6. Desenvolvimento 38 o período, respeitando a metodologia ágil escolhida, Scrum Gestão de projetos utilizando Scrum De acordo com o que foi apresentado na Seção 3.1 referente às principais etapas deste projeto, divididas em Pré-Produção, Produção e Pós produção, as mesmas não tiveram suas execuções realizadas de maneira totalmente linear ao passo de uma ter início apenas com o término da anterior. Utilizando um diagrama inspirado no trabalho de Macedo e Rodrigues (2012), em que as estapas de Produção e Pós-Produção se transformaram em esforços paralelos, agilizando a correção de erros ou mesmo a retirada de partes que se tornaram não funcionais no decorrer do projeto. A Figura 14 é referente ao fluxo de etapas que foram definidas neste projeto. Figura 14 Fluxo de tarefas desempenhadas durante o projeto. A fase de storyboard corresponde à fase de Roteiro e Conteúdo Uma breve descrição sobre as etapas apresentadas no fluxograma da Figura 14 serão tratadas com mais detalhes nas próximas seções, ainda neste capítulo Pré-Produção Esta fase se destaca pelo esforço analítico acerca do projeto idealizado. Serão discutidos aspectos que interliguem as características que o jogo exige e o torne praticável. São abordados conceitos como jogabilidade, concepção de personagens e demais objetos que compõem a cena, enredo ou Storyboarding(do inglês quadro de histórias, têm a ver com o fluxo que o jogo tomará em diferentes estágios), mecanismos de recompensas, como se dará o fluxo da UI(User Interface), ferramentas e tecnologias Produção e Pós-Produção Estas duas fases paralelizadas tratam de receber as conclusões do passo de Pré- Produção e tornás-la de fato partes concretas de um software, produzindo o conteúdo

40 Capítulo 6. Desenvolvimento 39 artístico, como as modelagens, texturização e animação de personagens, o design de botões e backgrounds. Todo este material produzido é transformado em objetos do jogo, colocados na engine onde é produzida toda a parte lógica do software em questão. Tudo que é finalizado passa por testes funcionais feitos pela equipe, com o intuito de verificar se de fato irá para o projeto final. Versões mais completas do jogo também são testadas, devendo ser atualizadas ou melhoradas de acordo com os defeitos encontrados. 6.2 Pré-Produção e Viabilidade A Pré-Produção é um dos primeiros passos do projeto, nela são tomadas as decisões iniciais com base nas necessidades e dificuldades que surgem durante o levantamento das idéias que fundamentam o jogo, no caso deste trabalho, o jogo Como Você Mora Viabilidade Técnica A busca por softwares que suportariam este projeto foi iniciada, sempre considerando que a versão anterior havia sido desenvolvida completamente na engine Unity3D. Foram analisados programas como Adobe Edge (ADOBE, 2015a), cuja linguagem de programação associada era o JavaScript, e Adobe Flash com ActionScript, ambos trabalhando com o aspecto de duas dimensões. Mas devido à várias características primordiais, a permanência na engine utilizada anteriormente se manteve, além de possibilitar a edição de jogos em duas e três dimensões, a Unity também permite que os softwares construídos possam ser portados para mais de 22 plataformas diferentes podendo ser implementados em três linguagens de programação, C#, JavaScript(UnityScript) e Boo, além de disponibilizar uma versão gratuita para desenvolvimento. No entanto, diferentemente da primeira versão, o atual projeto exigia uma área multidisciplinar mais ampla e pesquisas de viabilidade aplicadas ao cenário pretendido. À medida em que o projeto foi sendo formalizado o estudo sobre o que comporia o software era realizado em paralelo e, com a ajuda de bibliografias, vídeo-aulas e estudo de projetos já concluídos em Unity, notou-se gradualmente a eficácia desta ferramenta. Porém sua robustês trazia consigo alguns desafios que deveriam ser bem estudados, sua API é bastante extensa o que exige um grande esforço em pesquisa. Outro aspecto que também vislumbrado junto à engine foi a perspectiva do game, já que a Unity consegue trabalhar tanto com as dimensões 2D e 3D. Olhando-se para o projeto idealizado, a necessidade da projeção de um software mais imersivo foi evidenciada e gráficos em terceira dimensão pareciam transmitir melhor esta sensação ao usuário. Então um novo requisito foi identificado: uma ferramenta de modelagem que se comunicasse com a Unity3D e fornecesse os recursos para a construção dos gráficos esperados para o novo aplicativo da APO Digital, uma vez que a engine sozinha não era capaz de

41 Capítulo 6. Desenvolvimento 40 desempenhar todo o trabalho de modelagem e animação. Várias extensões são suportadas pela Unity3D provenientes de sete diferentes softwares de modelagem. Dentre estas, as quatro alternativas seguintes se destacaram: Blender3D SketchUp Maya 3ds Max Cinema4D No ínicio o software SketchUp, desenvolvido pela Google, foi utilizado para produção de algumas amostras, como mostrado na Figura 15. Figura 15 Primeiro teste de modelagem feito no Google SketchUp para o ambiente do jogo Como Você Mora. Portanto, a forma como a pintura das malhas é feita no SketchUp não obteve boa aceitação pela engine, fazendo com que o ambiente fosse importado assim como mostra a Figura 15, totalmente preenchido com a cor cinza. Outra dificuldade deste programa está presente na reprodução de formas curvas, mostrando melhor desempenho em formas retilíneas. Para isso, a necessidade de uma ferramenta com melhores recursos para o objetivo da pesquisa foi cogitada. O Blender ou Blender3D, surgiu como resposta trazendo vários benefícios, solucionando ambos os problemas encontrados em seu concorrente e disponibilizando um ambiente de produção mais ágil, mecanismo de texturização posteriormente incorporada aos objetos modelados e a possibilidade de animação deste mesmos objetos. Além de trabalhar com sua licença gratuita, o Blender consegue desempenho semelhante à

42 Capítulo 6. Desenvolvimento 41 softwares da área há muito consolidados, como 3ds Max, Maya e Cinema4D, cujos preços para sua utilização são um tanto quanto altos. Figura 16 Ícones referentes aos softwares de modelagem 3D, 3ds Max, Cinema4D, Blender, SketchUp e Maya, respectivamente da esquerda para a direita O método organizacional que melhor se adequou ao projeto, em se tratando de engenharia de software desde o início tem sido o Scrum. Na Pré-Produção, não apenas os requisitos técnicos são resolvidos como também levantamentos artísticos sobre como e o que será mostrado ao usuário durante o decorrer do jogo Viabilidade Artística e Fluidez A intenção do estudo de viabilidade artística e fluidez neste trabalho é proporcionar ao jogador a sensação de estar, tanto em um questionário, quanto em um jogo, e para isso o trabalho gráfico a ser desempenhado merece alta atenção para que possa passar ao usuário sentimentos agradáveis e que representem bem esta idéia. Com a intenção de motivar a criatividade das pessoas e tirá-las da realidade, aspectos surreais foram incorporados ao desenvolvimento. A concepção de um ambiente que está longe de nossos sentidos visuais e táteis proporciona graça e curiosidade. Esboços começaram a ser produzidos, muitos deles inspirados no game Monument Valley ganhador de onze prêmios durante os anos de 2014 e 2015, entre os títulos estão o melhor jogo para Ipad do ano de 2014 e eleito o melhor jogo portátil e móvel pela BAFTA (British Academy of Film and Television Arts) do ano de O enredo mostra a personagem principal no papel de uma princesa resolvendo certos quebra-cabeças ambientados algumas vezes em ilhas flutuantes, como mostrado na Figura 17. O Design inspirador e reconhecido se tornou fonte de referência. Monument Valley apresenta um teor de cores pastéis e harmônicas que não cansam os olhos dos jogadores, propõe cenários com a perspectiva 3D e construídos com a técnica Low Poly. A técnica

43 Capítulo 6. Desenvolvimento 42 Figura 17 Cenários do jogo Monument Valley produzido pelo estúdio indie Ustwo Low Poly surgiu a partir da construção de personagens de jogos eletrônicos. Como o próprio nome já diz, as malhas de modelagem são desenhadas com poucos polígonos, com o intuito de reduzir o processo de renderização da imagem, produzindo melhor desempenho. A câmera do jogo permanece estática mantendo o cenário atual de forma com que fique de quina, em um ângulo de aproximadamente 35 para o eixo x e 45 para y. Logo, a idéia de produzir uma ilha flutuante contendo uma mini-cidade pareceu ser promissora e, assim como Monument Valley, imergir o usuário ao contexto por meio de um personagem que poderia se movimentar e ter acesso a diversos locais situados nesta ilha. As questões do questionário seriam fortemente ligadas aos lugares pelo qual este personagem passasse, como por exemplo: caso o jogador entrasse em um condomínio, estaria conectado à questões sobre aquele tema. A Figura 18 mostra o esboço base para a montagem da ilha definitiva. O ponto de partida para chegar a um personagem surgiu da mesma filosofia que o cenário de ilha flutuante. Para que se comunicassem foi adicionado a este ser características abstratas das reais, tomando as precauções necessárias para que não causasse estranheza, representando uma espécie de avatar do próprio jogador. Em adição, para que fossem aumentados os níveis de interação entre avatar e usuário, foi proposta a capacidade de customização do personagem, que aproximaria as chances de alcançar as expectativas do usuário e torná-lo mais satisfeito, servindo também como um entretenimento suplementar. No entanto havia a preocupação com o excesso de liberdade, o que poderia desviar o foco do objetivo, que seriam as perguntas a serem respondidas. Então para que houvesse algum tipo de orientação para o usuário através dos olhos do avatar, mais um personagem surgiria. Um novo ser que viria a desempenhar as funções de explicar como o usuário deve

44 Capítulo 6. Desenvolvimento 43 Figura 18 Esboço produzido para futuras modelagens da ilha flutuante interagir com o ambiente em certos momentos. Nas cenas do questionário as perguntas que se seguiriam seriam como as falas deste personagem, ele assumiria a função de demonstrar ao respondente expressões de satisfação ao resolver suas questões. A esse personagem foi dado o nome de Pesquisador, com a aparência bem sugestiva ele facilitaria a comunicação com o respondente, ilustrado na Figura 19. Durante a fase de definição dos componentes da ilha foram feitos alguns estudos informais acerca das cores, geralmente, aquelas utilizladas em jogos consolidados, como Super Mario Word e Monument Valley. Várias das cores adotadas para compor as texturas foram inspiradas em paletas com o teor pastel, conforme Figura 20. Esse tipo de composição sugere uma agradável sensação de leveza aos componentes do jogo e casam muito bem com a proposta de modelagem Low Poly. A partir dos levantamentos e definições estabelecidas nesta etapa, reunindo-se os recursos que o game faria uso, concluiu-se o Brainstorm para a criação de uma estrutura sólida que deve margear todo o processo de produção, podendo sofrer algumas alterações porém sem que o foco no que se consolidou durante a etapa de Pré-Produção seja dispersado. 6.3 Produção e Pós-Produção Neste momento todo requisito pré-estabelecido na fase anterior, Seção 6.2, é colocado em prática, mostrando cada passo da evolução deste protótipo. Serão apresentadas informações acerca do hardware de dispositivos móveis voltado à jogos digitais, e de como

45 Capítulo 6. Desenvolvimento 44 Figura 19 O personagem Pesquisador modelado na ferramenta Blender foi feita a construção dos assets (ativos em português) que referenciam objetos ativos de um jogo, como o personagem, o cenário, elementos do cenário, tudo que de alguma forma será mostrado no game, utilizando a ferramenta para modelagem Blender. Esta seção trata também do acoplamento destes assests na engine Unity3D juntamente com especificações mais detalhadas das partes lógicas associadas e produzidas em C# e JavaScript(UnityScript).

46 Capítulo 6. Desenvolvimento 45 Figura 20 Paleta com cores pastéis Hardware de dispositivos móveis com foco em jogos Diferentemente de plataformas usuais como video-games e computadores, a prática de jogos digitais no contexto dos dispositivos móveis deve ser considerada pelo fato de possuírem um hardware mais específico e reduzido, logo, certos cuidados precisam ser tomados. Uma vez projetados com o intuito de privilegiar a comunicação em grande escala, estes dispositivos têm sido bastante utilizados para jogos e outras finalidades. A maior parte dos games depende do bom desempenho para que o fluxo aconteça de forma mais agradável e sem travamentos. Serão tratadas também as limitações de inputs, ou entradas, que o jogador pode utilizar para comunicar-se com a UI (User Interface). O desenvolvimento de jogos para mobile precisa ser simples, em razão de um processamento bastante limitado de alguns aparelhos, sendo este um dos principais problemas de projeto para este tipo de software. Há diferentes tipos de smartphones no mercado atual, variando seus poderes de processamento entre um a oito núcleos (quanto mais núcleos maior a capacidade de paralelizar processamento), com memórias RAM de no mínimo 256MB, podendo conter ou não GPUs (Unidade de Processamento Gráfico). A gama de diversidade é bastante alta no mercado e o projeto de um game para tal finalidade, têm como missão alcançar o maior número de pessoas possíveis, já que nem todas elas possuem renda para adquirir bons aparelhos. A tabela 2 demonstra a grande diferença entre dois aparelhos. Assim como a diversidade de celulares existe, consequentemente a diferença no tamanho dos displays também se faz presente. Caso um jogo seja desenvolvido com tamanho engessado, quando praticado em outros aparelhos cujas dimensões de tela e quantidade de pixels se diferem, todas as informações contidas na tela serão mostradas com algum

47 Capítulo 6. Desenvolvimento 46 Tabela 2 Diferenças de hardware entre os modelos Samsung Moment e Galaxy S6 Samsung M900 Moment Samsung Galaxy S6 Processador Sansung S3C6410 de 800MHz Quad-core 1.5 Ghz Cortex-A53+ Quad-core 2.1 GHz Cortex-A57 Memória RAM 256 MB 3 GB GPU Não possui ARM Mali-T760 Resolução 320x480 pixels 1440x2560 pixels Figura 21 Aparelhos Samsung Moment e Samsung Galaxy S6 tipo de distorção ou mesmo omissão das mesmas. Por isso, todos os objetos transmitidos por meio da interface devem ter seus tamanhos sempre reajustados dinâmicamente tomando como referência as dimensões de tela onde está sendo executado, para que toda a interface seja mostrada de forma fiel. Outra característica que se opõe as demais plataformas, é a quantidade reduzida de inputs disponíveis para a interação usuário-dispositivo. Jogos famosos para esta categoria, mostram sempre formas simples de diálogo com a tela, indo de poucos toques, utilizando o touch, até o uso do acelerômetro ou de voz para completarem suas ações. Como no jogo Flappy Bird, desenvolvido pelo programador vietnamita Nguyên Hà Dông, sucesso de downloads do ano de 2014, a única dinâmica era tocar a tela para que o pássaro pudesse se manter no ar e conseguisse passar por entre canos. A cada obstáculo deixado para trás um ponto era somado. Figura 22 Telas do game Flappy Bird e sua dinâmica

48 Capítulo 6. Desenvolvimento Processo de modelagem do personagem no Blender O processo de criação dos assets em 3D ocorre dentro da ferramenta Blender e para que tudo funcione perfeitamente na etapa final, alguns métodos devem ser aplicados de forma evolutiva conforme segue a série de tabelas abaixo, que detalharão como o personagem principal foi desenvolvido. Tabela 3 Descrição do Conceito de Arte associado ao Personagem principal Descrição do conceito da arte Imagem O personagem foi criado com aparência totalmente peculiar se comunicando muito bem com o ambiente abstrato a ele submetido, que seria uma ilha flutuante. Devido às diversas opções de gênero, um personagem cujo o estereótipo parecesse ser unissex, teria maiores chances de ser aceito por qualquer pessoa. Sua aparência agrada e seu formato cilindríco causa graça a quem já foi submetido ao software. O desenho serve como ponto de referência para que a modelagem possa ser realizada fielmente. Terminados todos os processos descritos nas Tabelas 3, 4, 5, 6, 7, 8 e 9 o avatar pode ser importado para a engine e ser utilizado como Asset, para o jogo. No entanto, para que fosse feita a etapa de customização do personagem, o processo de texturização requereu alguns passos além dos usuais. As partes que possibilitariam alteração eram correspondentes à face, cor de pele, corpo, cor do cabelo e sapatos. Todas essas partes deveriam ser produzidas separadamente para que o jogador associasse ao personagem as partes que ele mais se identificava. O personagem precisou ter associado a si não apenas um material, mas quatro, um para cada parte customizável, assim como mostra a Figura 23, exceto a face que teria de ser incorporada na Unity Processo de modelagem do Cenário A ilha flutuante também foi construída em partes, primeiramente foi feita a modelagem do pedaço de terra que ficaria pairando no ar, juntamente com as ruas, rio, pontes,

49 Capítulo 6. Desenvolvimento 48 Tabela 4 Operação de modelagem Descrição do Design gráfico de modelagem Imagem Conforme os parâmetros de economia de processamento e para o mantimento da identidade visual, a construção do personagem com poucos poligonos (Low Poly) é de primordial importância, geralmente baseada em planos. Uma melhor divisão da malha 3D nas áreas que sofrerão maior deformidade como em joelhos, tornozelos e cotovelos, produzem resultados melhores durante a fase de animação. trilhos, postes e fios, algumas árvores da qual não possuiriam interação também foram adicionadas. As demais construções foram produzidas uma a uma, obedecendo os processos referentes às tabelas 3, 4, 5 e 6, utilizando os mesmo métodos do personagem, porém sem a necessidade de serem atribuídas animações a elas. Como forma de recompensa por completar uma etapa do questionário ligada ao condomínio, por exemplo, esta localidade deverá ser colorida, motivando o usuário a pintar toda a ilha e consequentemente respondendo todas as perguntas. Os objetos feitos individualmente foram exportados para a Unity onde a maquete virtual foi finalizada, assim como apresentado na Figura Ambiente Unity e criação de cenas A engine Unity3D constrói seus jogos com a dinâmica básica de criação de cenas. Cada cena é composta com componentes necessários para que o game consiga desempenhar todas as funções planejadas. Por padrão, quando se cria uma cena, alguns componente vitais já se fazem presentes, como a câmera principal, apresentando a opção de projeção em perspectiva ou ortogonal; e a luz, que pode ser emitida de quatro maneiras diferentes, direcional, spot, pontual ou área. Toda cena produzida deve pertencer a uma espécie de vetor chamado scenes in build da qual a engine usa para guardar as cenas que de fato farão parte do software final. Toda cena que, por meio de script, é invocada a ser carregada deve estar inclusa a esta estrutura, que pode ser acessada por meio do atalho ctrl+shift+b, onde estarão presentes não apenas o vetor, mas também todas as opções de contrução. As definições sobre a plataforma para qual o jogo está sendo construído, como

50 Capítulo 6. Desenvolvimento 49 Descrição de abertura da malha 3D ou UV unwrap Do inglês unwrap, significa, desembrulhar, sendo essa a principal ação durante esse processo. Com a malha 3D finalizada, algumas arestas são marcadas como pontos de costura, ou seam, eles permitem que o personagem se divida e seja de certa forma planificado. A sigla UV, provém dos softwares 3D, para diferenciar as coodenadas da área de edição em três dimensões, XYZ, das de duas dimensões. Para esta última são associados denominações diferentes os eixos, onde UVW são correspondentes à XYZ. Como a coordenada W não é utilizada no processo de unwrap ela é ignorada. O processo de desembrulhar gera o UV mapping, ou mapeamento UV. Tabela 5 UV unwrap Imagem também as definições de jogador(player Settings), envolvendo ícones que representaram o aplicativo e demais ajustes que devem ser consultados antes da construção do aplicativo, também se encontram no Builder Settings Estilização das GUIs O termo GUI (Graphical User interface), faz referência à botões, campos de texto, menus, enfim, todo componente que ajude o usuário a se dialogar com o programa. Em games a construção de uma GUI adequada, limpa, objetiva e intuitiva, consegue, juntamente com algumas das aplicações teóricas de IHC como affordances e metáforas, fazer com que o reconhecimento e aprendizado por parte do usuário em relação ao software, se torne muito mais rápido. No entanto os botões de exibição padrão presentes no Unity, não apresentam muita qualidade quanto aos termos já citados acima, sem contar que não haverá comunicação com o design geral do jogo.

51 Capítulo 6. Desenvolvimento 50 Tabela 6 UV mapping Descrição de mapeamento ou UV mapping Imagem Com o mapeamento UV em mãos, inicia-se o processo de pintura usando o Photoshop. Caso a pintuta fosse efetuada no personagem em 3 dimensões, o tempo para finalizar poderia ser demasiado extenso. Logo que o arquivo.png é gerado ele é atribuido em forma de textura. Em fim a textura é colocada em um material que é atribuido ao personagem. Tabela 7 Rigging Descrição de Rigging ou esqueletos Imagem O processo de Rigging, ou esqueletização, consiste em associar ossos à malha 3D do personagem, como em um ser vivo. Cada osso deve ser colocado corretamente nas juntas que serão deformadas. Para se produzir interfaces de que satisfaçam as propostas apresentadas, a Unity apresenta uma recurso chamado GUIStyle, ele fará com que uma imagem seja associada ao botão nos diversos estados que ele se encontra, podendo haver diferentes estilos para a identificação do mesmo solto ou pressionado, sem contar que pode ser feita a atribuição

52 Capítulo 6. Desenvolvimento 51 Descrição da pintura de pesos ou Weight Paint Ao definir a posição corretado esqueleto, deve-se acrescentar interação entre o rig e a malha 3D. Este processo é feito atribuindo pesos aos ossos, que correspondem à influência que eles influirão sobre os poligonos do personagem, a ponto de deformá-los ou não. A cor vermelha simboliza influência máxima e a cor azul simboliza a mínima. Na figura ao lado o osso em evidência é aquele que corresponde à cabeça. Caso os ossos recebam uma associação tanto quanto errada uma pintura de peso(weight paint) será necessária, onde os pesos de influência devem ser recalculados para que o personagem se mova da maneira correta. O termo pintura é utilizado pelo fato do Blender utilizar de uma ferramenta semelhante a um pincel para esta ação. Tabela 8 Weight Paint imagem de qualquer fonte exterior, deixando não só a figura do botão personalizada, mas também o seu conteúdo escrito Prefabs Os objetos construídos na engine são geralmente associados a uma série de componentes que o tornam singular aos demais. Estes componentes darão o comportamento necessário para que o jogo e o usuário interajam com ele. Porém se este mesmo objeto tem a necessidade de ser instanciado mais de uma vez durante o jogo, a Unity permite torná-lo um prefab ou pré-fabricado. Todas as intâncias daquele prefab terão ações semelhantes. Durante a produção do protótipo da APO Digital, houve a produção de dois prefabs, o personagem principal e a ilha flutuante, ambos instâncias frequentes nas cenas até então

53 Capítulo 6. Desenvolvimento 52 Tabela 9 Animação Descrição das animações imagem Terminado o trabalho de configuração dos ossos com a malha 3D, o processo de animação se inicia. Neste momento são produzidas animações correspondentes Às ações que o personagem deve desempenhar. Movimentos como correr, ficar parado mas respirando, entre outros, são construídos de forma fluida e agradável imitando movimentos reais de característica humanóide. Tabela 10 Comparação entre botões padrões e estilizados na Unity Botões sem estilo Botões estilizados implementadas Lógica de customização do personagem principal Depois de receber o asset do personagem, devida a construção apresentada na Subseção 6.3.2, juntamente com as respectivas texturas correspondentes às partes que permitiriam customização, foi dado início ao processo de implementação das ações que

54 Capítulo 6. Desenvolvimento 53 Figura 23 Todas as partes customizáveis do avatar Figura 24 Ilha flutuante totalmente colorida

55 Capítulo 6. Desenvolvimento 54 os botões de troca fariam ao serem pressionados. Cada botão teria a tarefa de variar as opções para uma parte específica do corpo, totalizadas em cinco. Todo objeto pode ter associado a si um ou mais materiais dentro do ambiente Unity e quando são aplicados à malha 3D, além de se fixarem a ela, recebem um vetor onde são armazenados. Na Figura 25 nota-se que no vetor de materiais, situado dentro da aba Inspector à direita, as opções de shader dos materias relacionados ao cabelo, corpo, sapato e pele são sinalizados com a opção Diffuse permitindo que apenas uma textura de associe a ele. Figura 25 Tela de customização do personagem e ao lado direito o vetor de materiais que estão associados à malha 3D naquele momento. O algoritmo de customização inspirado nas aulas de Kinney 2012, baseia-se em atribuir a ação de troca de materiais aos botões. Uma vez que os botões que a Unity implementa por meio de GUIs são mostrados apenas em tempo de execução, toda função que fará uso destes botões devem estar contidas dentro do escopo da função OnGUI(), disponibilizada pela engine justamente para estes fins, assim como é apresentado na Figura 26. Todas as chamadas de funções que são executadas dentro dentro da OnGUI, possuem implementações semelhantes, menos a opção da face. Como o rosto do avatar também é uma opção customizável, e o local da qual ele ocupará na malha 3D sobreporá os materiais de pele, a opção de shader deve ser diferente das demais. A opção Decal faz com que um material principal e outro secundário possam ser adicionados, ao passo que ambos podem ser modificados separadamente. O trecho de código correspondente à troca da textura de face pode ser obervada na Figura 27. Com exceção da função ChangeFaceTexture, todas as outras funções como ChangeBodyMaterial, ChangeHairMaterial, ChangeShoes e ChangeSkinMaterial fazem uso da função ChangeMeshMaterial dentro de seus escopos. Esta realiza de fato a mudança do

56 Capítulo 6. Desenvolvimento 55 Figura 26 Parte do algoritmo de customização implementado na linguagem JavaScript(UnityScript), mostrando o conteúdo das funções OnGUI e ChangeBody- Material. Figura 27 Parte do algoritmo de customização, mostrando como é feita a troca da textura da face do personagem, sem com que o material associado a ela seja também trocado. material escolhido pelo usuário. Com o auxílio de uma estrutura de multipla escolha como um switch case, as opções disponíveis dos materiais vão sendo variadas de acordo com o clique dos botões. Durante as trocas é verificado se o vetor de materiais correspondente a parte trocada chegou ao fim para que possam ser reiniciadas as opções, assim como mostra a Figura 28. A cada material que é trocado pelo jogador em tempo real, a estrutura que guarda os materiais associadas ao personagem é totalmente substituída pela nova contendo a nova combinação. Caso as trocas sejam feitas corretamente a malha 3D do avatar será automaticamente atualizada.

57 Capítulo 6. Desenvolvimento 56 Figura 28 Parte do algoritmo de customização, correspondente à função ChangeMesh- Material Lógica de caminhamento do personagem entre os componentes da Ilha flutuante Como a idéia é fazer que o avatar se mova entre as oito localidades contidas na ilha flutuante, sendo que em cada uma delas estará contida uma parcela do questionário, foi desenvolvida uma lógica de caminhamento simples, baseada em alguns pontos de referência inserido na ilha, a fim de que o personagem se guie e tome o caminho correto. Os locais para onde o avatar pode ser mover são: hospital, condomínios, área de lazer, centro da cidade, shopping, árvore anciã, igreja e conjunto de casas. Os pontos que auxiliarão o personagem a chegar no seu destino podem ser verificados na Figura 29. Postos em um vetor, os pontos são utilizados na atualização da posição do personagem até que ele alcance seu destino. O usuário irá decidir em qual local irá entrar, com um simples toque sobre um dos oito locais. Para isso, foram estudadas e implementadas funções com o uso de RayCast, que nada mais é que um raio lançado até o infinito, tomando como partida a posição onde ocorreu o toque/clique na tela, identificando qualquer tipo de colisor que cruzar com este feixe. Uma vez que as oito localidades da ilha estiverem dotadas de colisores é possível identificá-las através deste método e notificar o avatar de seu futuro destino. Dados os índices dos pontos no vetor, de acordo com a Figura 30, o avatar sempre estará parado em apenas dois pontos, antes ou depois de entrar em algum local, estes são os pontos oito e dez. Quando o avatar está sobre um dos dois pontos (oito ou dez), o colisor contido

58 Capítulo 6. Desenvolvimento 57 Figura 29 Visão de topo da ilha flutuante; os marcadores vermelhos identificam os pontos cujo o avatar fará uso em seu caminhamento. Figura 30 Grafo com pontos utilizados na função de caminhamento do personagem. nestes pontos retorna o índice correspondente a ele durante o choque com o colisor do personagem. O índice do destino será disposto após o toque do usuário em alguma localidade, na Figura 31 a variável que recebe este número seria a numtouch. Posta numa estrutura de switch case, numtouch determina a cosntrução da lista path que contêm os pontos que o avatar usará para realizar o percorrimento de currentwaypoint até numtouch. A movimentação do personagem em si simulando sua caminhada através dos pontos pode ser verificada na função patrol implementada na Figura 32. Por meio da magnitude(um recurso disponível na API da engine), pode-se calcular a distância entre o personagem e os pontos utilizados para o caminhamento na ilha, sendo assim passível de cálculo o período que o avatar fará a caminhada. A patrol é chamada dentro da função Update também disponibilizada por padrão dentro dos scripts da engine, para aquelas