UmmodeloconceitualdeDesenvolvimentodeJogos Digitais

CENTRO UNIVERSITAacuteRIO SENAI BAHIA

PROGRAMA DE POacuteS-GRADUACcedilAtildeO EM MODELAGEM

COMPUTACIONAL E TECNOLOGIA INDUSTRIAL

Doutorado em Modelagem Computacional e Tecnologia Industrial

Tese de doutorado

Um modelo conceitual de Desenvolvimento de JogosDigitais sugestotildees e modificaccedilotildees no framework de

desenvolvimento Scrum

Apresentada por Marcelo Vera Cruz DinizOrientador Prof Dr Roberto Luiz Souza Monteiro

Co-orientador Prof a Dra Tereza Kelly Gomes Carneiro

Julho de 2017





Tese de doutorado




Co-orientadora Prof a Dra Tereza Kelly Gomes Carneiro

Julho de 2017

Marcelo Vera Cruz Diniz

Um modelo conceitual de Desenvolvimento de Jogos

Digitais sugestotildees e modificaccedilotildees no framework de


Tese de doutorado apresentada ao Programa de Poacutes-graduaccedilatildeoem Modelagem Computacional e Tecnologia Industrial Cursode Doutorado em Modelagem Computacional e Tecnologia In-dustrial do CENTRO UNIVERSITAacuteRIO SENAI BAHIA comorequisito parcial para a obtenccedilatildeo do tiacutetulo de Doutor em Mo-delagem Computacional e Tecnologia Industrial

Aacuterea de conhecimento Interdisciplinar

Orientador Prof Dr Roberto Luiz Souza MonteiroC U SENAI Bahia

Co-orientadora Prof a Dra Tereza Kelly Gomes CarneiroUNCISAL

SalvadorC U SENAI Bahia

2017

NDI - 04

D585m Diniz Marcelo Vera Cruz

Um modelo conceitual de desenvolvimento de jogos digitais sugestotildees e modificaccedilotildees no framework de desenvolvimento scrum Marcelo Vera Cruz Diniz ndash Salvador 2018

103 f il color

Orientador Prof Dr Roberto Luiz Souza Monteiro

Tese (Doutorado em Modelagem Computacional e Tecnologia Industrial) ndash

Programa de Poacutes-Graduaccedilatildeo Centro Universitaacuterio SENAI CIMATEC Salvador 2018

Inclui referecircncias 1 Jogos digitais-design 2 Metodologia-framework 3 Modelo-framework 4

Poker planning 5 Scrum I Centro Universitaacuterio SENAI CIMATEC II Monteiro Roberto Luiz Souza III Tiacutetulo

CDD 62000113

Ficha catalograacutefica elaborada pela Biblioteca do Centro Universitaacuterio SENAI CIMATEC

CENTRO UNIVERSITAacuteRIO SENAI BAHIAPrograma de Poacutes-graduaccedilatildeo em Modelagem Computacional e Tecnologia Industrial


A Banca Examinadora constituiacuteda pelos professores abaixo listados leram e recomendam

a aprovaccedilatildeo da Tese de doutorado intitulada ldquoUm modelo conceitual de Desenvolvimento

de Jogos Digitais sugestotildees e modificaccedilotildees no framework de desenvolvimento Scrum

apresentada no dia 21 de Julho de 2017 como requisito parcial para a obtenccedilatildeo do tiacutetulo

de Doutor em Modelagem Computacional e Tecnologia Industrial

OrientadorProf Dr Roberto Luiz Souza Monteiro

C U SENAI Bahia

Co-orientadoraProf a Dra Tereza Kelly Gomes Carneiro

UNCISAL

Membro interno da BancaProf Dr Hernane Borges de Barros Pereira

C U SENAI Bahia

Membro externo da BancaProf a Dra Ingrid Winkler

C U SENAI Bahia

Membro externo da BancaProf Dr Eduardo Manuel de Freitas Jorge

UNEB

Membro externo da BancaProf Dr Joseacute Roberto de Arauacutejo Fontoura

UNEB

Enzo Davi e Silvana Obri-gado pela oportunidade de pas-sar uma encarnaccedilatildeo ao lado devocecircs

Agradecimentos

A minha amada esposa Silvana e aos meus filhos Enzo e Davi pela paciecircncia e apoioem todos os momentos que passei nos uacuteltimos 4 anos Natildeo consigo imaginar como seria aminha vida sem vocecircs eu amo vocecircs Aos meus pais Luciano e Isabela e meu irmatildeo Ro-drigo pelo grande exemplo de vida que vocecircs me datildeo A Daiane Morbeck por construiruma famiacutelia com meu irmatildeo e trazer agrave Terra meu sobrinho Antocircnio Aos meus padrinhosItamar e Dinha por tudo que vocecircs me ensinaram nos uacuteltimos anos Ao meu cunhadoe primo Anderson e a sua linda famiacutelia Camila Nicole e Jullie Adoro vocecircs Agradeccedilopor ter todos vocecircs em minha vida

Aos meus orientadores Prof Dr Roberto Luiz Souza Monteiro e Prof a Dra Te-reza Kelly Gomes Carneiro eu natildeo tenho como expressar todo sentimento de gratidatildeoque tenho por vocecircs Aceitar orientar um aluno com cronograma de execuccedilatildeo da teseatrasado e com restriccedilotildees de tempo para dedicaccedilatildeo ao curso foi um ato de coragem e derespeito ao proacuteximo Obrigado por acreditarem em mim e na minha proposta de trabalho

Aos membros da minha banca Prof Dr Hernane Borges de Barros Pereira Prof aDra Ingrid Winkler Prof Dr Eduardo Manuel de Freitas Jorge e Prof Dr JoseacuteRoberto de Arauacutejo Fontoura por contribuirem para o aperfeiccediloamento da minha teseEspero um dia trabalhar com vocecircs em outros projetos

A dois grandes amigos que ganhei durante os uacutetimos anos Prof Dr Dielson PereiraHohenfeld Prof Dr Jancarlos Meneses Lapa e a minha madrinha acadecircmica Prof aMsa Luciacutelia Santa Rosa Vocecircs resignificaram a relaccedilatildeo que eu tenho com o IFBA

Ao meu guia espiritual por nunca desistir de mim e sempre em mostrar os caminhosda luz e da verdade Obrigado meu irmatildeo espero um dia poder retribuir tudo que vocecircfez por mim Que a luz do GADU faccedila os nossos caminhos se cruzarem por muitas en-carnaccedilotildees

E especialmente gostaria de agradecer ao meu filho Enzo O ano de 2016 foi cheio detrabalho pesquisa e dedicaccedilatildeo ao seu irmatildeo por causa dos cuidados que um bebecirc necessitaDevido a isso eu tive que dizer natildeo muitas vezes para vocecirc meu filho Desculpe-me es-pero que o Pai me decirc vida e sauacutede para passar muito tempo com vocecirc seu irmatildeo e sua matildee

Salvador Brasil Marcelo Vera Cruz Diniz21 de Julho de 2017

Enzo Papai conta uma histoacuteriaEu Conto papai Qual vocecirc querEnzo A do rato jiujiteiroEu Certo Aiiiiiii Boa noite meu filho

5

Resumo

Este trabalho propotildee com base em um modelo que define o processo de desenvolvi-mento de Jogos Digitais duas praacuteticas que objetivam eliminar problemas causados pelaindividualizaccedilatildeo do trabalho aumentar a cooperaccedilatildeo entre os membros da equipe de de-senvolvimento durante as reuniotildees de planejamento e diminuir problemas causados porfalhas nas estimativas das user stories O modelo proposto contempla as diferentes pers-pectivas dos jogadores e desenvolvedores de Jogos Digitais e apresenta uma estrutura quefavorece a concepccedilatildeo de jogos A partir do modelo proposto apresentamos um protocolopara descriccedilatildeo de Jogos Digitais que tem como principal objetivo aumentar o caraacutetercientiacutefico desses artefatos que normalmente se apresentam como objetos focados parao entretenimento A metodologia do estudo eacute de natureza qualitativa Neste trabalhomesclamos referecircncias da aacuterea de designer de Jogos Digitais Gamificaccedilatildeo e protolocos queserviram como base estrutural das nossas sugestotildees O resultado final dessa investigaccedilatildeopossibilitou a construccedilatildeo de um modelo cuja aplicaccedilatildeo potencializa a especializaccedilatildeo demetodologias e frameworks de desenvolvimento de Jogos Digitais

Palavras-chave Desenvolvimento Scrum Jogos Digitais Poker Planning estimativaModelo Metodologia Aacutegil

i

Abstract

This thesis proposes based on a model that defined the development process of DigitalGames two practices that aim to eliminate problems caused by Dualization of work in-crease cooperation between members of the development team during planning meetingsand reduce problems caused by wrong estimates of user stories The proposed modelcontemplates the different perspectives of players and Game Developers and presentsa structure that favors conception of games From the proposed model we present aprotocol for description of digital games that has as its main objective increased thescientific value of these artifacts that are usually presented as objects focused on enter-tainment The methodology of the study is qualitative In this study we used referencesfrom area like game designer of digital games gamification and protocols that served asstructural basis of our suggestions The end result of this investigation presents a mo-del whose application enhances the specialization of methodologies of Game Development

Keywords Development Scrum Digital Games Poker Planning Estimate ModelMethodology Agile

ii

Sumaacuterio

1 Introduccedilatildeo 111 Definiccedilatildeo do problema 112 Objetivo 6

121 Objetivos especiacuteficos 613 Limites e limitaccedilotildees 614 Pressupostos 715 Aspectos metodoloacutegicos 816 Organizaccedilatildeo da Tese de doutorado 12

2 Os Jogos Digitais e as Metodologias de Desenvolvimento 1421 O que eacute um jogo 1422 Por que gostamos dos Jogos Digitais 1723 A mecacircnica dos jogos 1924 Metodologias de Desenvolvimento de Jogos Digitais 21

241 Os primeiros passos 21242 O framework Scrum 25

25 Definindo os requisitos de um Jogo Digital 3026 Instrumentalizaccedilatildeo 3327 O protocolo ODD 3328 A piracircmide de elementos da gamificaccedilatildeo 3729 O modelo MDA 41

3 Modelo de Desenvolvimento de Jogos Digitais 4631 O Modelo de Desenvolvimento de Jogos Digitais 46

311 O objetivo 46312 As categorias e a relaccedilatildeo entre os seus itens 47313 As perspectivas dos desenvolvedores e jogadores 49314 O protocolo para descriccedilatildeo dos Jogos Digitais 50

4 Sugestotildees para o Framework Scrum 5441 Apresentaccedilatildeo 5442 O Poker Planning com jogadas colaborativas 5543 Verificaccedilatildeo multidisciplinar 6044 Visualizando as sugestotildees no framework Scrum 65

5 Conclusotildees e Consideraccedilotildees finais 7251 Conclusotildees 7252 Contribuiccedilotildees diretas 7553 Contribuiccedilotildees indiretas 7554 Contribuiccedilotildees enquanto pesquisador 7755 Atividades Futuras de Pesquisa 77

A Um exemplo de utitilizaccedilatildeodo Protocolo para descriccedilatildeo de Jogos Digi-tais 78A1 Apresentaccedilatildeo do Jogo Digital Tetris 78A2 Descriccedilatildeo do Tetris 79

iii

SUMAacuteRIO SUMAacuteRIO

Referecircncias 83

iv

Lista de Tabelas

11 Pressupostos e mecanismos de verificaccedilatildeo 7

21 As caracteriacutesticas da motivaccedilatildeo intriacutensica dos jogos 1922 Objetivos dos eventos no Scrum 3023 Elemento de PBL da trilogia Mass Effect e suas relaccedilotildees com as categorias

da piracircmide de elementos de gamificaccedilatildeo 41

31 Blocos e seccedilotildees do protocolo para descriccedilatildeo de Jogos Digitais 53

41 As cartas do baralho de Poker Planning e seus signifados 57

A1 Descriccedilatildeo do Jogo Digital Tetris 80A2 Continuaccedilatildeo da Tabela A1 Fonte elaborado pelo autor 81

v

Lista de Figuras

11 Ciclo baacutesico da Pesquisa-accedilatildeo 912 Principais autores estudados nesta tese 1113 Fluxo da pesquisa 13

21 Principais sensaccedilotildees do indiviacuteduo na realizaccedilatildeo de uma atividade ateacute atingiro estado de Flow 18

22 Metodologia de desenvolvimento em cascata 2223 Interaccedilatildeo entre usuaacuterios e os diferentes tipos de artefatos (EstoacuteriasSistemas

Computacionais e Jogos Digitais) 2524 Framework de desenvolvimento Scrum 2625 Personagens envolvidos no fluxo de trabalho do framework Scrum 2726 Eventos e artefatos do framework de desenvolvimento Scrum 2927 Estrutura de uma user storie 3128 Dois tipos de protoacutetipo 3129 Etapas da metodologia Google Sprint 32210 Estrutura do protocolo ODD 34211 Comparaccedilatildeo entre as duas versotildees do protocolo ODD 37212 Relaccedilatildeo entre jogos gamificaccedilatildeo brinquedos e designer luacutedico 39213 Piracircmide de elementos de gamificaccedilatildeo 39214 Elementos do processo de construccedilatildeo de um JD 42215 Fases do design iterativo 43216 Principais elementos de design sugeridos pelo framework MDA (Mecacircnica

Dinacircmica e Esteacutetica) representados pelas letras M D A respectivamente 45

31 Modelo de Desenvolvimento de Jogos Digitais (MDJD) 4932 Protocolo para descriccedilatildeo de Jogos Digitais 51

41 Cartas do baralho de Poker Planning 5742 Novas cartas para nova dinacircmica do Poker Planning 5843 Exemplo de estimativa de uma equipe com trecircs desenvolvedores 5944 Exemplo de estimativa apoacutes o Showdown 6045 Ciclo de Desenvolvimento guiado por testes TDD 6146 Exemplo de Programaccedilatildeo em pares 6247 Ciclo de Verificaccedilotildees Multidisciplinar 6348 Aplicaccedilatildeo do Poker Planning Colaborativo 6649 Cenas do Jogo Digital LIPISpace 67410 User stories das cenas ilustradas na Figura 49 67411 Jogadas para mensurar user stories 68412 Nova User storie criada para adicionar uma nova funcionalidade na cena

Ada Figura 49 68413 Aplicaccedilatildeo da Verificcedilatildeo Multidisciplinar 69414 Cenas do Jogo Digital SimGE 69415 Exemplo de utilizaccedilatildeo de uma das seccedilotildees do Protocolo para descriccedilatildeo de

Jogos Digitais 70416 Aplicaccedilatildeo do Protocolo para descriccedilatildeo de Jogos Digitais 71

vi

LISTA DE FIGURAS LISTA DE FIGURAS

A1 Game Boy console portaacutetil da Nintendo lanccedilado em 1989 79A2 As sete peccedilas originais do Jogo Digital Tetris lanccedilado em 1989 82A3 Conexatildeo entre dois consoles Game Boy 82

vii

Lista de Siglas

2D Duas dimensotildees3D Trecircs dimensotildeesARG Alternate Reality GamesCAPES Coordenaccedilatildeo de Aperfeiccediloamento de Pessoal de Niacutevel SuperiorDOD Definition of DoneEaD Educaccedilatildeo a DistacircnciaGV Google VenturesIBM Models based on individualsIDE Integrated Development EnvironmentIFBA Instituto Federal de Educaccedilatildeo Ciecircncia e Tecnologia da BahiaINPI Instituto Nacional da Propriedade IndustrialJD Jogos digitaisLIPI Laboratoacuterio Interdisciplinar de Praacuteticas InovadorasMDA Mechanics Dynamics and AestheticsMDJD Modelo de Desenvolvimento de Jogos DigitaisMEC Ministeacuterio da EducaccedilatildeoMJ Mecacircnica dos JogosMMO Massive Multiplayer OnlineNPC Non-Playable CharacterODD Overview Design concepts and DetailsUML Unified Modeling LanguagePBL Points Badges e LeaderboardsROI Retorno do InvestimentoSEBRAE Serviccedilo Brasileiro de Apoio agraves Micro e Pequenas EmpresasTDD Test Driven DevelopmentTIC Tecnologias de Informaccedilatildeo e ComunicaccedilatildeoXP eXtreme Programming

viii

Capiacutetulo Um

Introduccedilatildeo

Apresentamos aqui o caminho da pesquisa a definiccedilatildeo do problema os objetivos ospressupostos que a nortearam o aspectos metodoloacutegicos os limites e limitaccedilotildees do estudoe a organizaccedilatildeo da tese

11 Definiccedilatildeo do problema

Desde a deacutecada de 1970 o mercado dos viacutedeo games observa a popularidade dos JogosDigitais (JD) aumentar Pesquisas de agecircncias especializadas como SEBRAE e PGTapontam que o mercado mundial de JD movimentou US$ 57 bilhotildees em 2010 enquanto ode cinema movimentou US$ 318 bilhotildees Em 2011 o setor movimentou US$ 74 bilhotildeese no ano de 2015 as cifras ultrapassaram os US$ 90 bilhotildees (SEBRAE 2014) Para seter uma noccedilatildeo mais precisa do impacto de um JD em 2013 apenas o lanccedilamento deGrand Theft Auto V teve o custo de US$ 225 milhotildees e faturou US$ 800 milhotildees emapenas 24 horas De acordo com SEBRAE (2014) o jogo Angry Birds jaacute foi instaladoem mais de 500 milhotildees de celulares Para o mercado brasileiro em 2016 um montantede aproximadamente US$ 14 bilhotildees foram movimentados e as estimativas para 2017apontam que o mercado brasileiro movimentaraacute US$ 17 bilhotildees (FLEURY NAKANOCORDEIRO 2014) Especialistas estimam que em 2016 o mercado mundial de JD mo-vimentou aproximadamente US$ 86 bilhotildees e em 2017 os recursos movimentados poresse ramo da induacutestria do entretenimento vatildeo ultrapassar os US$ 106 bilhotildees com jogosvoltados para dispositivos moacuteveis como smartphones e tablets (NEWZOO 2016)

Outro ponto importante que ajuda a explicar a evoluccedilatildeo dos JD eacute o puacuteblico-alvo Essetipo de entretenimento antes voltado para o coletivo masculino ganhou e vem ganhandoespaccedilo entre as mulheres e as famiacutelias Pesquisas realizadas entre 2013 e 2016 mostramo nuacutemero crescente de mulheres que jogam viacutedeo games Em 2013 elas eram 14 dopuacuteblico gamer Em 2015 esse nuacutemero subiu para 471 e em 2016 elas ultrapassaram oshomens e atualmente satildeo 526 do puacuteblico consumidor dos JD (BRASIL 2015) Aleacutemdisso os dados das pesquisas nos apresentam um fato interessante 858 dos pais costu-mam jogar com os seus filhos Ou seja os JD jaacute se apresentam como um entretenimentofamiliar (BRASIL 2015 BRASIL 2016) Esse caso de estudo se explica porque a maioriados jogadores 62 estatildeo em idade adulta entre 25 e 54 anos (BRASIL 2016) fato quecontribui para perpetuaccedilatildeo da cultura dos viacutedeo games de uma geraccedilatildeo para outra

1

Capiacutetulo Um 11 Definiccedilatildeo do problema

Questotildees tecnoloacutegicas tambeacutem influenciaram a induacutestria e o puacuteblico-alvos dos JD Antesfocados apenas em consoles e computadores os JD estavam restritos a essas plataformasisso limitava a abrangecircncia desse artefato devido agraves limitaccedilotildees e necessidades operacionaisdesses equipamentos Poreacutem o surgimento de novas tecnologias e dos dispositivos moacuteveisexpandiu as opccedilotildees de plataformas computacionais(FLEURY NAKANO CORDEIRO2014) Devido a isso atualmente podemos encontrar JD em computadores smartphonestablets consoles e Smarts Tvs A plataforma mais utilizada pelos jogadores brasileiros eacute osmartphone 772 dos usuaacuterios Logo apoacutes vem o computador com 669 os consolesque eacute a escolha de 586 dos jogadores os tablets 247 e por uacuteltimo as smarts Tv com101 dos usuaacuterios (SEBRAE 2014 NEWZOO 2016 BRASIL 2015 BRASIL 2016)

Esses trecircs fatores (movimentaccedilatildeo financeira puacuteblico-alvo e fatores tecnoloacutegicos) criarammuitas oportunidades de negoacutecio devido agrave pluralidade do puacuteblico-alvo e agrave grande apro-ximaccedilatildeo que os atuais consumidores de JD tecircm das Tecnologias de Informaccedilatildeo e Co-municaccedilatildeo (TIC) fato que proporcionou o crescimento vertiginoso do mercado de JD eo fortalecimento de estuacutedios de desenvolvimento de games de pequeno meacutedio e grandeporte (MCGONIGAL 2011 MASTROCOLA 2015)

O processo de desenvolvimento de JD eacute um assunto que singulariza grande parte dos ga-mes developments devido ao produto final que esse processo objetiva construir De acordocom Crawford (1984) os JD representam o mundo real a partir de duas perspectivas quenatildeo satildeo excludentes a subjetiva e a objetiva A perspectiva subjetiva brota e se alimentada perspectiva objetiva Esse ciclo se sustenta por causa de uma peculiaridade que os JDpossuem que eacute a de concretizar anseios e desejos humanos atraveacutes das experiecircncias queo jogador vivencia durante o jogo Devido a essa caracteriacutestica natildeo podemos conside-rar os JD como simplesmente softwares Os JD satildeo mais do que softwares (KEITH 2010)

Consequentemente os JD natildeo devem seguir os mesmos padrotildees e metodologias utiliza-dos para o desenvolvimento de softwares objetivando evitar insucessos de planejamentocomo desperdiacutecio de tempo esforccedilo e dinheiro ou fracassos comerciais como construirjogos que natildeo vatildeo atender agraves demandas do seu puacuteblico-alvo (SCHELL 2014 SALENZIMMERMAN 2012)

As metodologias de desenvolvimento mais indicadas para a construccedilatildeo de JD satildeo as me-todologias interativas (SCHELL 2014 FULLERTON 2014) Eacute possiacutevel utilizar metodo-

2


logias lineares como por exemplo a metodologia cascata (ROYCE 1970) Poreacutem essametodologia soacute eacute bem aplicada para o desenvolvimento de jogos simples como um jogode cartas ou ateacute mesmo um JD pequeno Nesses casos eacute admissiacutevel pensar em todoplanejamento e estrateacutegias de gamificaccedilatildeo antes de comeccedilar o desenvolvimento do jogoPoreacutem em jogos de meacutedio ou grande porte cujos protoacutetipos necessitam de dias para seremconstruiacutedos devido ao trabalho intenso de arte e programaccedilatildeo o processo de construccedilatildeoeacute necessariamente interativo e aleacutem disso natildeo eacute possiacutevel definir quantas iteraccedilotildees seratildeonecessaacuterias para conclusatildeo satisfatoacuteria do produto (SCHELL 2014)

O uso das metodologias Aacutegeis para o desenvolvimento de JD tornou-se uma praacutetica muitocomum devido a caracteriacutesticas como desenvolvimento incremental cooperaccedilatildeo e adap-taccedilatildeo (GODOY BARBOSA 2010) Aleacutem dessas propriedades encontramos no conjuntode princiacutepios que norteiam as metodologias Aacutegeis valores que evidenciam o produto finalcomo o foco principal dessas metodologias e natildeo o processo Os princiacutepios que norteiamas metodologias Aacutegeis foram sumarizados em 2001 por um conjunto de desenvolvedoresexperientes e deu origem ao manifesto Aacutegil que valoriza a interaccedilatildeo entre os indiviacuteduosa colaboraccedilatildeo com o usuaacuterio final e a prototipagem (AacuteGIL 2011)

Esse conjunto de propriedades possibilita que frameworks como Lean XP e Scrum sejambem indicados para o desenvolvimento de JD (KEITH 2010) Neste trabalho focamos anossa atenccedilatildeo no framework Scrum Iremos sugerir adaptaccedilotildees em dois eventos importan-tes do Scrum Sprint Planning e Sprint Execution Essas sugestotildees nascem da necessidadede diminuir ou eliminar problemas causados por estimativas malfeitas no momento dadefiniccedilatildeo do escopo dos requisitos dos JD e pela individualizaccedilatildeo do trabalho

Embora muitos desenvolvedores jaacute tenham experiecircncia no processo de desenvolvimentode sistemas e ateacute na utilizaccedilatildeo do Scrum como processo de desenvolvimento existemespecificidades e caracteriacutesticas peculiares ao processo de criaccedilatildeo de JD que satildeo cruciaispara construccedilatildeo de jogos bem-sucedidos (GODOY BARBOSA 2010) Devido a isso oaperfeiccediloamento de metodologias e praacuteticas voltadas para o desenvolvimento de JD podemevitar problemas de planejamento reduzir os custos de desenvolvimento e evitar atrasosnas entregas e no lanccedilamento dos jogos (GREGORY 2010)

De acordo com Keith (2010) Scrum eacute um framework para o desenvolvimento de pro-dutos complexos Natildeo eacute uma metodologia porque natildeo possui um conjunto de praacuteticasque determinam o que os desenvolvedores tecircm que fazer Esse framework impulsiona odesenvolvimento atraveacutes de uma metodologia incremental e interativa auto gerenciaacutevel

3


multidisciplinar e cooperativa

O Scrum possui um conjunto de eventos (Sprint Planning Sprint Execution Daily ScrumSprint Review e Retrospective) e artefatos (Product Backlog Sprint Backlog e Incrementoou Produtos) que alicerccedilam as suas bases fundamentais Desde que esses atributos e osprinciacutepios da metodologia Aacutegil sejam mantidos eacute possiacutevel fazer adaptaccedilotildees no Scrum paraa realidade de sua empresa ou projeto (KEITH 2010 SUTHERLAND 2016)

Petrillo et al (2008) afirma que os principais problemas encontrados durante o desenvol-vimento de JD estatildeo relacionados a falhas de planejamento definiccedilatildeo do escopo dos jogose gerenciamento de problemas causados pela caracteriacutestica multidisciplinar da equipe dedesenvolvimento Embora equipes compostas por membros de diferentes aacutereas do co-nhecimento proporcionem um ambiente criativo as caracteriacutesticas laborais das profissotildeesterminam dividindo o grupo entre programadores e artiacutestas fato que dificulta a comuni-caccedilatildeo entre os membros da equipe favorece a individualizaccedilatildeo do trabalho e prejudica abusca de um estado de equiliacutebrio entre os aspectos artisticos e teacutecnicos do JD geralmentechamado pelo literatura de fun of the game ou find the fun no qual os desejo e anseiosdo puacuteblico-alvo os jogadores satildeo atendidos (HUNICKE LEBLANC ZUBEK 2004 PE-TRILLO et al 2008 KANODE HADDAD 2009 GODOY BARBOSA 2010 KEITH2010)

Devido a isso tendo como premissa que os JD satildeo artefatos cujo escopo superam ossistemas computacionais e que o trabalho colaborativo de uma equipe multidisciplinar eacuteum fator indispensaacutevel para o desenvolvimento de JD o problema que esta tese pretenderesolver eacute Como adaptar o framework de desenvolvimento Scrum para evitar problemasde gestatildeo causados por falhas na definiccedilatildeo de escopo dos requisitos dos JD e pela indivi-dualizaccedilatildeo do trabalho durante o processo de desenvolvimento de JD

Assim o presente estudo defende a necessidade de formalizar praacuteticas colaborativas paradefiniccedilatildeo do escopo dos requisitos dos JD e para evitar a individualizaccedilatildeo do trabalho nodesenvolvimento de JD Para tanto utilizamos o protocolo ODD (GRIMM et al 2006GRIMM et al 2010) a Piracircmide de Elementos da Gamificaccedilatildeo (WERBACH HUNTER2012) e o modelo MDA (HUNICKE LEBLANC ZUBEK 2004) como base para cons-truccedilatildeo de um modelo que define como funciona o processo de desenvolvimento de um JDconsiderando a perspectiva dos jogadores e dos desenvolvedores o Modelo de Desenvol-vimento de Jogos Digitais MDJD A partir desse modelo apresentamos um protocolopara descriccedilatildeo de JD que pode ser utilizado como um documento de design ou como uma

4


ferramenta para aumentar o caraacuteter cientiacuteficos de serious games JD que tem objetivosfocados na educaccedilatildeo informaccedilatildeo e treinamento (ABT 1987 MICHAEL CHEN 2005)

Aleacutem disso apresentamos duas sugestotildees que objetivam adaptar o framework Scrumpara o desenvolvimento de JD A primeira modifica a praacutetica gamificada Poker Planning(GRENNING 2002) e tem o propoacutesisto de aumentar a participaccedilatildeo de todos os membrosda equipe de desenvolvimento durante o processo de definiccedilatildeo do escopo dos requisitos dosJD A segunda sugestatildeo eacute novo item de verificaccedilatildeo no documento de Definition of Donedefiniccedilatildeo de pronto (DOD) Ela se chama Verificaccedilatildeo Multidisciplinar e tem o intuito deevitar a individualizaccedilatildeo do trabalho e a perda de aspectos multidisciplinares que foramprojetados durante a reuniatildeo de planejamento do sprint Ela foi idealizada com base emduas caracteriacutesticas fundamentais da metodologia eXtreming Programming (XP) a Pro-gramaccedilatildeo em pares e o Desenvolvimento guiado por teste (TDD) (BECK 2009) e colocaos jogadores - os usuaacuterios finais dos JD - dentro do processo de desenvolvimento dos jogos

O ineditismo deste trabalho estaacute nos quatro produtos aqui apresentados Durante a pes-quisa bibliograacutefica que efetuamos para efetivaccedilatildeo desta pesquisa encontramos trabalhosque apresentam adaptaccedilotildees para gestatildeo de projetos de desenvolvimento de JD (GODOYBARBOSA 2010 SCHILD WALTER MASUCH 2010 ALBINO SOUZA PRADO2014) trabalhos com o foco voltado para colaboraccedilatildeo da equipe de desenvolvimento(MUSIL et al 2010) soluccedilotildees para trabalhar de forma distribuiacuteda durante o processo demensuraccedilatildeo do tamanho dos requisitos (MOLOslashKKEN-OslashSTVOLD HAUGEN BENES-TAD 2008 ORACLE 2014) trabalhos que objetivam unir as estimativas de diferentesdesenvolvedores experientes (BLESS 2010) e trabalhos que tecircm o objetivo de descreverJD (HENSE MANDL 2012 PETRY et al 2013) Poreacutem natildeo encontramos modelosprotocolos e praacuteticas que solucionem o problema que estamos tratando da forma que noacuteso apresentamos

Aleacutem disso destacamos que as praacuteticas que apresentamos nesta tese natildeo criam ou adici-onam novas estruturas ao framework Scrum E devido a isso elas podem ser utilizadaspor qualquer equipe de desenvolvimento sem ferir a atual cultura de trabalho do time dedesenvolvedores

Sendo assim o presente trabalho defende que a aplicaccedilatildeo de um modelo que relacione aequipe de desenvolvedores como os usuaacuterios finais a partir das suas diferentes perspec-tivas viabilizaraacute a gestatildeo mais eficiente do processo de desenvolvimento de Jogos Digitais

5

Capiacutetulo Um 12 Objetivo

A presente pesquisa se alinha com a proposta de trabalho do PPG MCTI visto que elabusca estudar compreender e aprimorar a estrutura do processos de desenvolvimento deJD mediado por modelagem A estrateacutegia utilizada nesta pesquisa permite a reflexotildees e aconstruccedilatildeo de contribuiccedilotildees teoacuterico-metodoloacutegicas para o aprimoramento de um processoindustrial

12 Objetivo

Propor adaptaccedilotildees no framework Scrum tendo como base um modelo que define o pro-cesso de desenvolvimento de JD e praacuteticas colaborativas a partir da perspectiva dosjogadores e dos desenvolvedores

121 Objetivos especiacuteficos

bull Analisar fragilidades no processo de desenvolvimento de JD

bull Construir um modelo que defina o processo de desenvolvimento de JD a partir daperspectiva dos jogadores e dos desenvolvedores

bull Elaborar adaptaccedilotildees no framework Scrum baseadas nas fragilidades encontradas noprocesso de desenvolvimento de JD

13 Limites e limitaccedilotildees

O primeiro limite admitido nesta pesquisa eacute que os JD cujos processos de desenvolvimentoforam analisados para construccedilatildeo das sugestotildees foram JD educacionais de pequeno portee sem fins lucrativos

O segundo limite eacute que ainda natildeo aplicamos os produtos gerados nesta pesquisa (Modeloprotocolo e as duas sugestotildees de adaptaccedilatildeo do framework Scrum) no desenvolvimento deum JD Esse conjunto de artefatos seratildeo validados por profissionais e pesquisadores daaacuterea em um dos trabalhos futuros apoacutes esta pesquisa

O terceiro limite foi que durante o processo de desenvolvimentos dos dois JD cujo pro-cessos foram analisados natildeo realizamos ou utilizamos todos os eventos e artefatos do

6

Capiacutetulo Um 14 Pressupostos

framework Scrum Noacutes adaptamos o processo para realidade da empresa e das equipes dedesenvolvimento Nos dois projetos realizamos Sprints de trecircs semanas reuniotildees sema-nais (sempre nas segundas agraves 9 horas da manhatilde) Sprint review Produck backlog e Sprintbacklog

14 Pressupostos

De acordo com Carneiro (2015) os pressupostos funcionam como uma linha-guia de umapesquisa empiacuterica Considerando que os JD satildeo objetos de estudo que transcendem o es-copo dos sistemas computacionais convencionais e possuem especificidades que precisamser consideradas durante o seu desenvolvimento (HUNICKE LEBLANC ZUBEK 2004KEITH 2010) foram formulados trecircs pressupostos apresentados na Tabela 11 que nor-tearam todo o desenvolvimento do estudo Para cada pressuposto foi determinado ummecanismo de verificaccedilatildeo e operacionalizaccedilatildeo

Pressupostos Mecanismo de verificaccedilatildeo (A+B)Procedimento (A) Operacionalizaccedilatildeo (B)

1 Um modelo que relacionee aproxime o jogador do pro-cesso de desenvolvimento deJD eacute um fator preponderantepara construccedilatildeo de experiecircn-cias emocionais engajadoras

Estudo teoacuterico sobre ModelosJogos Digitais e Gamificaccedilatildeo

Anaacutelise dos dados e constru-ccedilatildeo de um modelo

2 Existem especificidades noprocesso de desenvolvimentode JD que precisam ser tra-tadas para evitar fracassos deplanejamento e a construccedilatildeode jogos enfadonhos

Estudo teoacuterico sobre proces-sos de desenvolvimento de jo-gos digitais

Anaacutelise dos dados e identifica-ccedilatildeo dos principais problemasrelatados durante o desenvol-vimento de Jogos Digitais

3 A colaboraccedilatildeo eacute o pontocentral para efetivaccedilatildeo do pro-jeto com equipes multidiscipli-nares

Estudo teoacuterico sobre o fra-mework Scrum

Anaacutelise dos eventos e artefa-tos do Scrum e definiccedilatildeo dassugestotildees de modificaccedilatildeo

Tabela 11 Pressupostos e mecanismos de verificaccedilatildeo Fonte Adaptado de Carneiro (2015)

O primeiro pressuposto apresentado na Tabela 11 estaacute relacionado com o atores envol-vidos no desenvolvimento de JD e com os conceitos que norteiam esse processo Como aincerteza eacute um paracircmetro presente em grande parte do processo de desenvolvimento deJD a inclusatildeo do jogador no processo de construccedilatildeo dos JD viabiliza a definiccedilatildeo de umalinha guia para equipe de desenvolvimento Com isso poderemos definir um modelo queapresente os principais conceitos do desenvolvimento de JD considerando as perspectivasdos jogadores e desenvolvedores

7

Capiacutetulo Um 15 Aspectos metodoloacutegicos

Posteriormente apresentamos um pressuposto que expotildee a nossa preocupaccedilatildeo com as es-pecificidades do processo de desenvolvimento de JD O maior objetivo do segundo pressu-posto eacute evitar fracassos dos JD Para isso realizaremos um estudo teoacuterico sobre processosde desenvolvimento de JD e a partir desse estudo e da anaacutelise dos dados identificaremosum dos principais problemas encontrados durante o desenvolvimento de JD

Por fim apresentamos o terceito pressuposto e nesta suposiccedilatildeo falamos sobre um pontoimportante para o desenvolvimento de JD a colaboraccedilatildeo Chamamos a atenccedilatildeo para esseponto por que existem aspectos multidisciplinares que satildeo fundamentais para construccedilatildeode JD bem sucedidos Geralmente os conceitos multidisciplinares satildeo perdidos por men-suraccedilotildees mal feitas e falta de comunicaccedilatildeo durante o desenvolvimento do JD O estudoteoacuterico do framework de desenvolvimento Scrum possibilitaraacute a apresentar propostas quetem o objetivo de eliminar problemas caudados por essas falhas

15 Aspectos metodoloacutegicos

A proposta metodoloacutegica aplicada nesta pesquisa foi a pesquisa-accedilatildeo Essa escolha se jus-tifica devido a natureza dessa pesquisa De acordo com Thiollent (2011) a Pesquisa-accedilatildeoeacute um tipo de pesquisa de base empiacuterica que eacute concebida e executada com estreita relaccedilatildeocom accedilatildeo ou com a soluccedilatildeo de um problema no qual o pesquisador esta envolvido

Os objetos de estudo desta pesquisa foram os processos de desenvolvimento de dois JD OSimGe 1 foi desenvolvido durante a Coordenaccedilatildeo do Programa Profuncionaacuterio uma accedilatildeodo Instituto Fedaral da Bahia IFBA em parceria com o Ministeacuteio da Educaccedilatildeo MECque ofertou 3000 vagas em quatro cursos teacutecnicos na modalidade EaD para trabalhadoresdas escolas puacuteblica do Estado da Bahia O segundo JD foi o LIPISpace 2 desenvolvidono Laboratoacuterio Interdisciplinar de Praacuteticas Inovadoras LIPI e tem o foco voltado para oensino da Fiacutesica Moderna no Enino Meacutedio Esses JD foram desenvolvidos entre os mesesde Fevereiro de 2013 e Julho de 2015 Em nenhum momento os membros das equipes dedesenvolvimento foram analisados todas as observaccedilotildees foram feitas sobre os processosde desenvolvimento dos JD

De acordo com Westbrook (1995) Coughlan amp Coghlan (2002) Tripp (2005) Thiollent1Jogo Digital Educacional registrado no INPI Nuacutemero de Registro 512015000928-12Jogo Digital Educacional registrado no INPI Nuacutemero de Registro 512016001116-5

8


(2011) o ciclo baacutesico da Pesquisa-accedilatildeo tem quatro fases (Planejar Agir Descrever e Ava-liar) Poreacutem para apresentar mais detalhadamente o percurso metodoloacutegico realizadodurante esta pesquisa utilizaremos um conjunto de cinco fases apresentado em Mello etal (2012) ilustrado na Figura 11 que adaptou o ciclo baacutesico da Pesquisa-accedilatildeo a partirdas quatro referecircncia citadas acima

Figura 11 Ciclo baacutesico da Pesquisa-accedilatildeo Fonte Adaptado de (MELLO et al 2012)

A fase de Planejamento da Pesquisa-accedilatildeo eacute composta de quatro etapas A primeiraeacute Iniciar o projeto de Pesquisa-accedilatildeo e pode ser efetivada por dois tipos diferentes deprojetos projetos orientados agrave pesquisa ou projetos orientados a problemas Nos proje-tos orientados a pesquisa o pesquisador inicialmente realiza uma pesquisa bibliograacutefica eencontra lacunas que causam problemas para aacuterea de estudo da sua pesquisa Posterior-mente o pesquisador iraacute definir cenaacuterios que seratildeo utilizados para propor soluccedilotildees para oproblema encontrado (MELLO et al 2012)

A nossa pesquisa se enquadra na segunda possibilidade trata-se da iniciaccedilatildeo dirigida porproblema Nessa abordagem os integrantes de uma organizaccedilatildeo ou de um grupo de tra-balho se deparam com um problema e um especialista se predispotildee a resolvecirc-lo (MELLO

9


et al 2012) A peculiaridade desta pesquisa eacute que o pesquisador vivenciou o problemaos processos de desenvolvimento dos JD SimGe e LIPISpace e depois efetuou as anaacutelisesnecessaacuterias para propor as sugestotildees que fizemos nesta pesquisa

A segunda etapa da fase de Planejamento da Pesquisa-accedilatildeo eacute definir a estrutura conceituale teoacuterica Nesta fase noacutes construiacutemos a fundamentaccedilatildeo teoacuterica da pesquisa Definimos oEstado da Arte do campo de pesquisa que estaacutevamos estudando a partir da bibliografiaclaacutessica e das obras mais recentes da aacuterea Durante esta fase identificamos o conjunto deconceitos e publicaccedilotildees que se alinhavam com as lacunas que observamos durante o de-senvolvimento dos JD SimGE e LIPISpace Neste momento noacutes construiacutemos os objetivos(geral e especiacuteficos) desta tese e definimos os trecircs pressupostos que nos guiaram durantea execuccedilatildeo desta pesquisa

A terceira etapa da primeira fase do ciclo de Pesquisa-accedilatildeo eacute selecionar unidade de anaacutelisee coleta de dados Nesta etapa precisamos responder duas perguntas importantes Ondea Pesquisa-accedilatildeo seraacute realizada (local) e Como seraacute realizada a coleta de dados Como ainiciaccedilatildeo da nossa pesquisa foi motivada por um problema o local da pesquisa jaacute estavadefinido Os dois JD - cujos processos de desenvolvimento foram devidamente analisados- foram construiacutedos no Instituto Federal da Bahia (IFBA) Natildeo aplicamos questionaacuteriospara e natildeo fizemos entrevistas

A uacuteltima etapa da fase de Planejamento da Pesquisa-accedilatildeo eacute definir contexto e propoacutesitoSeguindo as definiccedilotildees apresentadas em Thiollent (2011) noacutes definos o tema e a aacutereade atuaccedilatildeo desta pesquisa nesta etapa Aqui percebemos a necessidade de construir oudefinir modificaccedilotildees em um modelo que obtivesse caracteriacutesticas estruturantes devido agravenatureza da atividade de desenvolvimento de JD Foi neste ponto que percebemos que oFramework Scrum seria uma estrutura importante dentro do andamento desta tese

Na fase de Coleta de Dados utilizamos as bases de perioacutedicos online PUBME SciloWeb of Science Google Acadecircmico Thomson Reuters e Academiaedu aleacutem do Bancode Teses da CAPES Em nenhuma das bases de conhecimento pesquisadas foram uti-lizados criteacuterios de recorte temporal O nosso principal objetivo era encontrar todas aspublicaccedilotildees que trataram desse assunto Para isso utilizamos palavras-chave pertinen-tes agrave temaacutetica definida e algumas variaccedilotildees e correlaccedilotildees com outros temas de pesquisacomo game designer game development desenvolvimento de jogos digitais engenhariade software software engeniaring gamificaccedilatildeo e gamification

10


Vale destacar que aleacutem das bases de conhecimento utilizadas nesta pesquisa utilizamostambeacutem livros claacutessicos amplamente utilizados e referenciados da aacuterea Aleacutem disso afir-mamos que embora muitas vezes o Google Acadecircmico e Academiaedu sejam contestadospela comunidade acadecircmica no contexto desta pesquisa eles foram utilizados para am-pliar a abrangecircncia da investigaccedilatildeo em busca de publicaccedilotildees sobre o tema estudado

O conjunto de trabalhos que encontramos foi organizado em seis categorias Jogos JogosDigitais Game Designer Gamificaccedilatildeo Modelagem e Scrum Essa divisatildeo facilitou o tra-balho exploratoacuterio e possibilitou a identificaccedilatildeo dos limites teoacutericos que existem entre asdiferentes aacutereas que estaacutevamos pesquisando A Figura 12 apresenta os principais autorespesquisados segundo a sua contribuiccedilatildeo para este trabalho

Figura 12 Principais autores estudados nesta tese Fonte elaborado pelo autor

Depois de definir o conjunto de artigos e autores que formariam o universo de obras quesustentariam os nossos modelos e sugestotildees iniciamos a fase de Anaacutelise de dados ePlanejamento de accedilotildees Durante essa etapa noacutes comparamos o conjunto de informa-ccedilotildees e modelos que encontramos Logo percebemos a convergecircncia entre as observaccedilotildeesque fizemos durante o desenvolvimento dos JD SimGE e LIPISpace e a literatura queencontramos A lacuna teoacuterica que noacutes enxergamos no decorrer da construccedilatildeo dos JD

11

Capiacutetulo Um 16 Organizaccedilatildeo da Tese de doutorado

ficou evidente e a partir dessa constataccedilatildeo comeccedilamos a projetar as accedilotildees que seriamnecessaacuterias para sanar essas falhas e evitar fracassos no desenvolvimento de JD

Em seguida iniciamos a fase de Implementar accedilotildees e sistematizamos as sugestotildees queadicionaram duas praacuteticas colaborativas voltadas para a construccedilatildeo de JD no frameworkde desenvolvimento Scrum Por fim analisamos os resultados obtidos neste projeto econcluiacutemos a pesquisa expondo os trabalhos futuros que podem dar continuidade a esteprojeto de pesquisa Os resultados parciais dessa tese foram publicados em artigos cien-tiacuteficos que estatildeo disponiacuteveis nos anexos deste trabalho

Por fim noacutes Avaliamos os resultados obtidos fazendo uma reflexatildeo sobre todos osprodutos gerados por esta tese (o modelo o protocolo e as sugestotildees) e construiacutemos asconsideraccedilotildees finais nesta pesquisa

16 Organizaccedilatildeo da Tese de doutorado

Este documento estaacute estruturado em cinco capiacutetulos os quais estatildeo conectados em funccedilatildeodo objetivo da pesquisa doutoral Destaca-se que todo o processo foi interconectado emesmo que aqui seja apresentado como um fluxo contiacutenuo com iniacutecio meio e fim comoilustrado na Figura 13 esta construccedilatildeo natildeo ocorreu de forma linear Na verdade foiuma construccedilatildeo onde se permitiu constantes visitas e revisitas aos capiacutetulos inicialmentepropostos e onde a revisatildeo bibliograacutefica permeou toda a construccedilatildeo do texto

bull Capiacutetulo 1 - Introduccedilatildeo Contextualiza o acircmbito no qual a pesquisa propostaestaacute inserida Apresenta a definiccedilatildeo do problema objetivos e justificativas da pes-quisa

bull Capiacutetulo 2 - Os Jogos Digitais e as Metodologias de DesenvolvimentoApresenta os referenciais teoacutericos que baseam a proposta do estudo desenvolvido

bull Capiacutetulo 3 - Modelo de Desenvolvimento de Jogos Digitais Apresenta oModelo que relaciona os principais conceitos envolvidos no processo de Desevolvi-mento de Jogos Digitais e o protocolo para descriccedilatildeo dos Jogos Digitais

bull Capiacutetulo 4 - Sugestotildees para o Framework Scrum Apresenta as sugestotildees queobjetivam potencializar a colaboraccedilatildeo entre os membros da equipe de desenvolvi-mento

12


bull Capiacutetulo 5 - Consideraccedilotildees Finais Apresenta as conclusotildees contribuiccedilotildees ealgumas sugestotildees de atividades de pesquisa a serem desenvolvidas no futuro

Figura 13 Fluxo da pesquisa Fonte Adaptado de (CARNEIRO 2015)

13

Capiacutetulo Dois

Os Jogos Digitais e as Metodologias de

Desenvolvimento

Aqui seratildeo apresentados os referenciais teoacutericos que iratildeo basear a definiccedilatildeo dos conceitosjogos jogos digitais e framework Scrum que seratildeo as bases para a proposta do estudodesenvolvido

21 O que eacute um jogo

Nas ultimas deacutecadas pesquisadores tentaram encontrar uma definiccedilatildeo formal e fechadapara os jogos (ABT 1987 CRAWFORD 1984 COSTIKYAN 1998 PARLETT 1999SALEN ZIMMERMAN 2012 SUITS 2014) Todas elas falharam por natildeo conseguiremconstruir uma definiccedilatildeo que contemplasse as diferentes perspectivas e natureza de todosos jogos Poreacutem as diferentes linhas de pensamento utilizadas para conceituar um jogopermitem uma anaacutelise interessante dos aspectos importantes e necessaacuterios para compre-ender a essecircncia dos jogos

O estudo acadecircmico e teoacuterico dos jogos foi iniciado pelo filoacutesofo e antropoacutelogo Johan Hui-zinga na sua obra Homo Ludens Neste trabalho Huizinga afirma que os jogos fazemparte da formaccedilatildeo cultural da humanidade e ressalta que eles precedem o homem Parasustentar as suas afirmaccedilotildees Huizinga alega que durante a observaccedilatildeo de animais (catildeese lobos) brincando poderiacuteamos perceber regras (por exemplo a mordida natildeo pode serforte) e ainda uma boa dose de satisfaccedilatildeo Outro aspecto muito importante que Hui-zinga traz em sua obra satildeo as caracteriacutesticas de um jogo Elas satildeo a voluntariedade(o jogador natildeo eacute obrigado a jogar) o espaccedilo (um jogo tem um espaccedilo proacuteprio para serjogado) o estado mental (o jogador fica completamente focado no jogo) a natildeo seriedade(os problemas do dia a dia satildeo esquecidos durante o jogo) e a formaccedilatildeo de grupos sociais(grupos e comunidades formadas para o jogo) Essas cinco caracteriacutesticas levam o jogadore um estado de concentraccedilatildeo que Huizinga chamou de ciacuterculo maacutegico que eacute teoricamentedefinido como o espaccedilo fiacutesico e conceitual onde os jogos acontecem (HUIZINGA 1931)

O autor Roger Caillois tambeacutem trouxe grandes contribuiccedilotildees para o estudo dos jogoscom a publicaccedilatildeo Os jogos e os Homens Em sua obra Caillois afirma que o jogo eacute umaatividade livre dinacircmica improdutiva regida por regras e ficccedilatildeo Todavia o grande foco

14

Capiacutetulo Dois 21 O que eacute um jogo

do trabalho de Caillois estaacute no estudo das atitudes psicoloacutegicas impulsionadas pelos jo-gos Para o autor os jogos possuem quatro fundamentos primaacuterios agon (competiccedilatildeo)ilinx (vertigem) mimicry (simulaccedilatildeo) e alea (sorte) Eacute justamente sobre esses princiacutepiosque os impulsos luacutedicos dos jogos atuam no ser humano A competiccedilatildeo a sensaccedilatildeo deadrenalina a fuga da realidade e a imprevisibilidade nos levam a um estado mental quenos proporciona sentimentos prazerosos No entanto Caillois tambeacutem chama a atenccedilatildeopara os problemas que os jogos trazem A deturpaccedilatildeo do agon ilinx mimicry e do aleapode levar respectivamente agrave violecircncia ao desejo de poder agrave supersticcedilatildeo e agrave mudanccedila depersonalidade (CALLOIS 1990)

Falando de um ponto de vista muito mais teacutecnico e voltado para o designer e a jogabi-lidade (gameplay) de um jogo Salen amp Zimmerman (2012) afirmam que um jogo eacute umsistema no qual os jogadores se envolvem em um conflito artificial definido por regrasque resulta em uma saiacuteda quantificaacutevel Para os autores os jogos possuem uma estruturaque possibilita o seu entendimento Essa estrutura eacute dividida em trecircs esquemas primaacuteriosas regras estatildeo focadas nas estruturas norteadoras e limitantes intriacutensecas dos jogos nainteraccedilatildeo luacutedica que enfatiza a interaccedilatildeo do jogador com o jogo e com os outros jogado-res e na cultura que contextualiza e destaca os aspectos sociais em que o jogo estaacute imerso

McGonigal (2011) enxerga os jogos de um ponto de vista diferente Para a autora osjogos satildeo caminhos que trilhamos para atingir um objetivo maior Ela valoriza muito otrabalho colaborativo e afirma que os jogos possuem quatro caracteriacutesticas baacutesicas obje-tivo regras sistema de feedback e participaccedilatildeo voluntaacuteria O objetivo eacute o ponto focal quefaz os jogadores agirem em funccedilatildeo de um propoacutesito maior As regras satildeo as limitaccedilotildeesque os jogadores precisam obedecer para atingir os seus objetivos O sistema de feedbackpossibilita que o jogador tenha a noccedilatildeo exata do seu atual estado dentro do jogo Por fima participaccedilatildeo voluntaacuteria implica na aceitaccedilatildeo das regras e do sistema de funcionamentodo jogo

Poreacutem a grande contribuiccedilatildeo de McGonigal (2011) estaacute no entendimento que ela apresentasobre a influecircncia que os jogos tecircm nas vidas das pessoas Entre 2001 e 2012 McGonigaldesenvolveu uma seacuterie de jogos todos desafiando os jogadores a resolver problemas reaisos chamados Alternate Reality Games (ARGs) Jogos de Realidade Alternativa Escolhe-mos dois exemplos para ilustrar esse tipo de iniciativa

Em 30 de Abril de 2007 McGonigal e um grupo de voluntaacuterios espalhados por 32 paiacutesesiniciaram o jogo World Without Oil Esse jogo tinha o objetivo de criar um ambiente

15


no qual os jogadores poderiam experimentar um mundo sem combustiacuteveis derivados dopetroacuteleo Todas as situaccedilotildees vividas deram origem a um banco de informaccedilotildees que relatapossibilidades e accedilotildees para promover uma adaptaccedilatildeo a uma possiacutevel mudanccedila de fonteenergeacutetica O World Without Oil ganhou a menccedilatildeo honrosa do evento Prix Green awardfor Environmental Art em 2008 (MCGONIGAL 2014)

O segundo exemplo de aplicaccedilatildeo dos jogos na vida real escolhido foi o projeto SuperbetterLanccedilado em 2012 o Superbetter tinha o objetivo ajudar na reconstruccedilatildeo da autoestima deseus jogadores Mais de 250000 jogadores participaram desse jogo para transpor proble-mas como depressatildeo anorexia insocircnia dores crocircnicas no corpo e traumatismos cranianosOs jogadores foram convidados a criar uma identidade secreta um avatar baseado emseu super-heroacutei preferido Esse avatar ajudava os jogadores a realizar tarefas (divididasem vaacuterias sub-tarefas) antes consideradas impossiacuteveis (MCGONIGAL 2014)

Kapp (2012) baseado nos conceitos de Salen amp Zimmerman (2012) e utilizando a teoriada diversatildeo de Koster (2013) como um guia para o desenvolvimento de jogos define jogoscomo

um sistema no qual jogadores se envolvem em um desafio abs-trato definido por regras interatividade e feedback que resultaem uma saiacuteda quantificaacutevel e frequentemente provoca uma rea-ccedilatildeo emocional (KAPP 2012)

Partindo de uma definiccedilatildeo bem ampla encontrada em Camargo (2006) Magne Gaslanddefine jogos como um espaccedilo de decisatildeo com regras recompensas e perdas O espaccedilo dedecisatildeo refere-se agraves diversas possibilidades que um jogador tem em diferentes situaccedilotildeesdo jogo Uma escolha leva o jogador a outros espaccedilos de decisatildeo e as sucessivas deci-sotildees tomadas por um jogador define o seu desempenho durante o jogo (GAringSLAND 2011)

As regras satildeo o conjunto de limitaccedilotildees a que o jogador deve obedecer dentro do espaccedilode decisatildeo Elas definem a dinacircmica do jogo e estatildeo diretamente relacionadas com ainteraccedilatildeo dos jogadores com o ambiente As recompensas satildeo os benefiacutecios dados aos jo-gadores durante o jogo Elas podem ser ilustradas com caminhos mais curtos para atingiro objetivo itens extras medalhas pontuaccedilotildees e novas aacutereas de exploraccedilatildeo As perdasestatildeo relacionadas a puniccedilotildees e tambeacutem agrave falta de recompensas Elas podem aparecercomo caminhos errados que obrigam o jogador a refazer tarefas um nuacutemero maior deadversaacuterios ou penalizaccedilatildeo na pontuaccedilatildeo Poreacutem o ponto mais importante relacionado agraves

16

Capiacutetulo Dois 22 Por que gostamos dos Jogos Digitais

recompensas e perdas eacute o feedback que o jogo daacute ao jogador do seu atual estado no jogo(GAringSLAND 2011)

22 Por que gostamos dos Jogos Digitais

De um modo geral a presenccedila dos jogos digitais em computadores dispositivos moacuteveisou consoles cresceu muito nas uacuteltimas deacutecadas (SEBRAE 2014 FLEURY NAKANOCORDEIRO 2014 NEWZOO 2016) Esse aumento pode ser notado no meio comerciale em ambientes acadecircmicos atraveacutes de iniciativas nacionais e internacionais que utilizamos jogos como fonte de estudos e elementos norteadores de praacuteticas pedagoacutegicas (ALVES2012) O poder inovador dos JD cativa e motiva pessoas devido agraves diferentes formas dediversatildeo que eles podem proporcionar (GAringSLAND 2011)

No livro intitulado ldquoA teoria da diversatildeo para designer de jogosrdquo Koster (2013) defendeque a diversatildeo eacute um caminho para mudar o comportamento das pessoas para melhor Se-gundo o autor a diversatildeo eacute causada por estiacutemulos fiacutesicos e quiacutemicos no sistema nervosoque ocorrem atraveacutes de descargas de endorfinas no ceacuterebro Essas descargas proporcionamemoccedilotildees quando executamos alguma atividade que noacutes gostamos como escutar muacutesicaassistir a filmes ou ler livros Com os jogos digitais natildeo eacute diferente

O conceito de diversatildeo que gira em torno dos jogos encontra suporte na teoria do Flow(CSIKSZENTMIHALYI 1997) A definiccedilatildeo de Flow estaacute pautada em um estado deconcentraccedilatildeo que uma pessoa se encontra quando estaacute executando uma atividade a pontode mais nada ao seu redor ser importante pois a proacutepria atividade proporciona umaexperiecircncia de prazer e um estado de satisfaccedilatildeo Para Csikszentmihalyi (1997) o estadode Flow eacute

a forma como as pessoas descrevem seu estado de espiacuterito quandoa consciecircncia estaacute harmoniosamente ordenada e elas querem se-guir o que estatildeo fazendo para seu proacuteprio bem (CSIKSZENT-MIHALYI 1997)

Este estado de espiacuterito descrito por Mihaly eacute alcanccedilado quando encontramos o equiliacutebrioentre as potencialidades e as limitaccedilotildees das pessoas atraveacutes de atividades que as levam anovos desafios Conforme ilustra a Figura 21 ao iniciar um novo desafio o indiviacuteduo seencontra em um estado de ansiedade (E1) poreacutem em pouco tempo o indiviacuteduo adquire

17


habilidade e essa situaccedilatildeo muda para o estado de teacutedio (E2) porque o desafio natildeo estaacutemais agrave altura da habilidade do indiviacuteduo Quando um novo desafio eacute posto ao indiviacuteduoele volta para um estado de ansiedade alto (E3) e vai adquirindo mais habilidades paraconseguir superar o novo desafio e atingir um novo estado de satisfaccedilatildeo (E4)

Figura 21 Principais sensaccedilotildees do indiviacuteduo na realizaccedilatildeo de uma atividade ateacute atingir o estadode Flow Fonte Adaptado de (CSIKSZENTMIHALYI 1997)

Analisando a Figura 21 verifica-se que o indiviacuteduo atinge o estado de Flow em dois mo-mentos (E1) e (E4) Esse equiliacutebrio entre os desafios e as habilidades de uma pessoas eacuteatingido quando pelo menos um dos oito elementos da teoria do Flow (desafios viaacuteveisconcentraccedilatildeo objetivos claros feedback imersatildeo controle da situaccedilatildeo catarse perda dasensaccedilatildeo de tempo) eacute citado apoacutes uma atividade prazerosa (CSIKSZENTMIHALYI 1997)

Devido a isso podemos fazer uma associaccedilatildeo direta entre a teoria do Flow e os JD To-dos os jogos que possuem uma grande aceitaccedilatildeo do seu puacuteblico-alvo tecircm a capacidadede manter o equiliacutebrio entre o niacutevel de desafio e o niacutevel de habilidade do jogador Elesmantecircm o jogador em um constante estado de Flow ou seja o jogo eacute a sua proacutepria fontede prazer jogando sem expectativa de algum benefiacutecio futuro mas simplesmente pelodesejo de participar da experiecircncia (FARDO 2013)

Diferentes autores estudam os JD a partir de pontos de vista particulares mas existe umponto de interseccedilatildeo onde as diferentes opiniotildees convergem para o mesmo lugar Os JDsatildeo cativantes devido ao impacto direto que eles tecircm sobre os aspectos cognitivos sociaise emocionais dos jogadores (MCGONIGAL 2011 ALVES 2012 GEE 2003)

18

Capiacutetulo Dois 23 A mecacircnica dos jogos

23 A mecacircnica dos jogos

Assim como na definiccedilatildeo de jogos eacute possiacutevel encontrar muitos pontos de ambiguidade nadefiniccedilatildeo de Mecacircnica dos Jogos (MJ) (LUNDGREN BJORK 2003 KOSTER 2013)Para iniciar a anaacutelise do conceito de MJ vamos utilizar uma definiccedilatildeo ampla sem nospreocupamos com explicaccedilotildees precisas de cada elemento Para isso utilizaremos o conceitoapresentado por Garingsland (2011) que define MJ como

o conjunto de elementos estrateacutegias ou padrotildees que compotildeemas regras de um jogo e contribuem para construccedilatildeo de ciclos defeedback (GAringSLAND 2011)

Falando de um ponto de vista empresarial e com o foco voltado para os negoacutecios poreacutemcom uma grande base conceitual na mecacircnica dos jogos Werbach amp Hunter (2012) apre-sentaram um conjunto de exemplos e criaram um ambiente que direciona o leitor para adefiniccedilatildeo de MJ de forma intuitiva Na sua obra Werbach amp Hunter (2012) utilizaram otermo PBL (Points Badges e Leaderboards) para referenciar os elementos mais primitivosdos jogos (pontos medalhas e tabelas de posicionamento) e os relaciona com a criaccedilatildeode ambientes (virtuais ou empresariais) que privilegiam a competecircncia a autonomia eo relacionamento Essas aptidotildees possuem propriedades (ilustradas na Tabela 21) quepossibilitam a construccedilatildeo de atividades motivantes Elas concretizam a MJ

Competecircncia Autonomia RelacionamentoResoluccedilatildeo de problemas Foco no jogadorusuaacuterio Objetivos clarosSenso de progresso Experimentaccedilatildeo (sem medo

de cometer erros)Atividades com significado (aimportacircncia do conjunto detarefas)

feedback Constantes Personalizaccedilatildeo Interaccedilatildeo social (com os pa-res)

Tabela 21 As caracteriacutesticas da motivaccedilatildeo intriacutensica dos jogos Fonte (WERBACH HUNTER2012)

Ou seja para Werbach amp Hunter (2012) a competecircncia do jogador eacute evidenciada pela re-soluccedilatildeo de problemas que deixam claro para ele seu progresso dentro do ambiente de jogoatraveacutes de feedbacks constantes que expressam o atual estado do jogador A automoniaestaacute baseada nas atividades que centralizam o jogador em uma constante experimentaccedilatildeoem um ambiente que pode ser adaptado para as suas necessidades E o relacionamento eacuteevidenciado pelas relaccedilotildees sociais que satildeo construiacutedas em torno do propoacutesito maior que oconjunto de atividades buscam alcanccedilar

Partindo da definiccedilatildeo de Garingsland (2011) e utilizando a ambientalizaccedilatildeo de Werbach amp

19


Hunter (2012) definimos Mecacircnica dos Jogos como um conjunto de estruturas e estra-teacutegias que se relacionam para proporcionar experimentaccedilatildeo atraveacutes das regras e ciclosconstantes de feedback ambientalizaccedilatildeo pelas interaccedilotildees do jogador com seus pares ecom o jogo e aperfeiccediloamento por meio do progresso do jogador no ambiente de jogo

A partir desse ponto eacute possiacutevel notar que esse conceito de MJ natildeo eacute exclusivo dos jogosPodemos encontrar exemplos do uso de MJ em nossas vidas Empresas jaacute utilizavam asloacutegicas das recompensas e da pontuaccedilatildeo para treinamento de seus funcionaacuterios progra-mas de televisatildeo mantinham ou aumentavam o nuacutemero de espectadores utilizando esseselementos empresas de vendas de produtos e propaganda utilizavam MJ para aumentara sua malha de vendedores com as famosas piracircmides Os elementos da MJ nos datildeo osenso de conquista que nos diferencia perante outras pessoas (ALVES MINHO DINIZ2014) disponiacutevel no apecircndice

Uma outra forma de perceber a utilizaccedilatildeo de elementos da MJ eacute pensar no experimento deBurrhus Frederic Skinner conhecido como Skinner Box a caixa de Skinner (SKINNER1953) Neste experimento Burrhus Skinner modificou o comportamento de pombos eratos utilizando recompensas e puniccedilotildees Os animais utilizavam alguns dispositivos mecacirc-nicos como bototildees e alavancas para ganhar recompensas comida ou para evitar puniccedilotildees- pequenas descargas eleacutetricas Neste ponto eacute possiacutevel fazer uma relaccedilatildeo direta entre osjogos especialmente os JD e uma cacircmara de condicionamento Ambos satildeo estruturadose amparados por um conjunto de elementos de MJ para deixar claro ao jogador o seuatual estado dentro do ambiente de jogo

Entretanto destacamos que utilizar conjunto de elementos e estrateacutegias para construirciclos de feedback natildeo eacute necessariamente algo ruim A aplicaccedilatildeo da MJ aprimora habili-dades e aumenta a experiecircncia dos sujeitos sobre um determinado assunto Essa eacute uma dasrazotildees pelas quais pessoas passam de 4 a 8 horas por dia jogando (MCGONIGAL 2011)Isso estaacute intimamente associado ao desejo de alcanccedilar o objetivo final do jogo e perceber oseu progresso nos niacuteveis do jogo (ROUSE 2010) Aleacutem disso existe uma grande diferenccedilaentre os objetivos e conceitos apresentados no trabalho de Skinner (1953) e a definiccedilatildeo dejogo de Garingsland (2011) O primeiro estaacute claramente baseado no comportamentalismo osegundo foca sua atenccedilotildees na experimentaccedilatildeo e nas livres escolhas do jogador

Aleacutem dos argumentos acima existem fontes acadecircmicas que corroboram a favor dos JDBransford Brown amp Cocking (1999) e Schank (1999) apresentam em seus trabalhos dadosresultados e argumentos para afirmar que o processo de aprendizagem acontece atraveacutes de

20

Capiacutetulo Dois 24 Metodologias de Desenvolvimento de Jogos Digitais

experiecircncias Este atual entendimento eacute completamente oposto ao antigo que afirmavaque a mente humana funcionava como um grande computador fazendo associaccedilotildees sim-boacutelicas utilizando regras para tomadas de decisatildeo (BRANSFORD BROWN COCKING1999)

24 Metodologias de Desenvolvimento de Jogos Digitais

O ambiente as condiccedilotildees e a organizaccedilatildeo dos anos pioneiros do desenvolvimento de JD fo-ram completamente extintos Tudo mudou a exigecircncia dos clientes a natureza dos jogosas plataformas computacionais os profissionais envolvidos e as cifras empenhadas nesseprocesso A figura solitaacuteria do desenvolvedor que era responsaacutevel por toda concepccedilatildeo doJD (programaccedilatildeo e artiacutestica) deu lugar a um exeacutercito de especialistas que custa caro eprecisa desenvolver um produto que atenda agraves expectativas dos jogadores e gere lucro paraos seus empregadores Essas mudanccedilas foram traumaacuteticas muitos erros foram cometidosdevido a utilizaccedilatildeo de metodologias que natildeo eram adequadas para o desenvolvimento deJD (KEITH 2010) Nesta seccedilatildeo iremos apresentar os principais eventos e metodologiasque contribuiram para evoluccedilatildeo do processo de construccedilatildeo de JD

241 Os primeiros passos

No iniacutecio os jogos digitais natildeo exigiam muito esforccedilo artiacutesto ou de programaccedilatildeo duranteo seu desenvolvimento Eles eram projetados para serem executados em equipamentosespeciacuteficos e tinham um ciclo de desenvolvimento muito curto Nos anos 1970 e no iniacuteciodos anos 1980 uma pequena fraccedilatildeo do custo do lanccedilamento de um JD estava no desen-volvimento A maior parte dos recursos eram aplicados na construccedilatildeo do hardware quegeralmente eram caixas de metal ou de madeira com um conjunto de componentes ele-trocircnicos que eram projetadas para executar um uacutenico jogo (COHEN 1984 BAGNALL2005)

Como grande parte do investimento estava no hardware nesta eacutepoca eacute muito comum con-truir o equipamento e somente depois iniciar a construccedilatildeo do JD Empresas como a Atariaplicavam um modelo de negoacutecio no qual o JD era desenvolvido em um curto aspaccedilo detempo aproximadamente um mecircs Se no final desse periacuteodo o JD natildeo fosse bom eleera simplesmente jogado fora e o desenvolvimento de um novo JD era iniciado Essaspraacuteticas mudaram quando as definiccedilotildees da lei de Moore (MOORE 2006) comeccedilaram ainfluenciar a produccedilatildeo de computadores domeacutesticos que possuiacuteam processadores de baixo

21


custo e grande poder de processamento Essa nova plataforma computacional possibilitouo desenvolvimento de JD mais sofisticados e levou agrave produccedilatildeo de JD a um novo patamar

Com o desenvolvimento e o barateamento dos computadores domeacutesticos novas possibi-lidades surgiram para induacutestria dos JD Os Jogos Digitais passaram a explorar os novosrecursos de multimiacutedia dos computadores e em pouco mais de 10 anos as equipes dedesenvolvimento passaram de um grupo de quatro ou cinco programadores para timesmultidisciplinares de 40 a 50 desenvolvedores Neste ponto o custo de desenvolvimentodos JD jaacute era muito maior do que o custo do hardware e para diminuir os risco de falhase desperdiacutecio de recursos as empresas de desenvolvimento de JD passaram a adotar asmetodologias de desenvolvimento de software em particular a metodologia de desenvol-vimento em cascata (KEITH 2010)

A ideia geral da metodologia em cascata ilustrada na Figura 22 eacute que o processo dedesenvolvimento de softwares deve acontecer seguindo uma seacuterie de etapas sequenciaisCada etapa daacute origem a um produto e agrave medida que o projeto vai avanccedilando entre asfases o seu custo vai aumentando devido ao nuacutemeo de recursos e horas necessaacuterias paraexecuccedilatildeo do projeto As fases iniciais da metodologia em cascata estatildeo associadas a etapasde planejamento O desenvolvimento de software ocorre nas etapas do meio e as etapasfinais satildeo destinadas a integraccedilatildeo e teste do software (ROYCE 1970)

Figura 22 Metodologia de desenvolvimento em cascata Fonte Adaptado de Royce (1970)

Poreacutem existe um problema que torna essa metodologia inapropriada para o desenvolvi-mento de JD Embora exista a possibilidade de iteraccedilatildeo entre as etapas da metodologiacascata grande parte do planejamento eacute feita nas etapas iniciais do projeto O opostoacontece com os testes a maioria eacute efetuada nas etapas finais (KEITH 2010 SCHELL

22


2014) A distacircncia que existe entre o planejamento e os testes e a natureza linear dasetapas de planejamento implementaccedilatildeo e teste dificulta a busca de um estado de equiliacute-brio entre os aspectos artiacutesticos e teacutecnicos do JD que Godoy amp Barbosa (2010) custumamchamar de fun of the game e Keith (2010) refere-se como find the fun no qual os desejos eanseios do puacuteblico-alvo os jogadores satildeo atendidos Quando esse estado de equiliacutebro natildeoeacute encontrado geralmente os JD natildeo alcanccedilam os indicadores (nuacutemero de vendas margemde lucro aceitaccedilatildeo do puacuteblico dentre outros) que a empresa esperava

Aleacutem dos motivos anteriores existem outras razotildees que impulsionam a busca de meacutetodosmais eficientes para o desenvolvimento de JD A necessidade de compor equipes multi-disciplinares para construccedilatildeo de JD sofisticados aumentou bastante o custo de produccedilatildeodeles (KEITH 2010 SALEN ZIMMERMAN 2012 SCHELL 2014) Devido a isso em-presas de desenvolvimento buscaram soluccedilotildees para contornar esses problemas que tiveramimpacto direto na produccedilatildeo dos JD A primeira soluccedilatildeo encontrada pelas empresas de de-senvolvimento de JD foi lanccedilar jogos com as mesmas caracteriacutesticas (objetivos narrativase mecacircnica de jogos semelhantes) objetivando fidelizar seus clientes Poreacutem essa medidateve repercusatildeo direta na falta de inovaccedilatildeo dos JD

A segunda soluccedilatildeo teve um impacto ainda maior nos jogos Para reduzir os custos asempresas de desenvolvimento comeccedilaram a diminuir o conteuacutedo dos jogos (fases me-nores narrativas curtas menos trabalho artiacutestico) fato que teve repercussatildeo direta naqualidade dos JD Por fim as empresas comeccedilaram a montar equipes pequenas paraconstruccedilatildeo dos jogos e contratar profissionais com menos experiecircncia Isso aumentou aquantidade de trabalho que cada desenvolvedor tinha que executar e afastou os desen-volvedores mais experientes (programadores e artistas) do mercado de desenvolvimentode JD fato que ajudou a deteriorar o ambiente de trabalho (COHEN 1984 BAG-NALL 2005 KEITH 2010)

A junccedilatildeo desses trecircs problemas (falta de inovaccedilatildeo reduccedilatildeo do conteuacutedo e degradaccedilatildeo doambiente de trabalho) causados por tentativas frustradas de empresas que natildeo consegui-ram se adaptar a uma nova realidade do mercado de desenvolvimento de JD aliada aogrande fracasso comercial da maior empresa de desenvolvimento de JD da eacutepoca a Atarie a popularizaccedilatildeo dos computadores domeacutesticos deu origem a um evento que a literaturada aacuterea chama de A Crise dos Viacutedeo Games (KEITH 2010 RABIN 2012)

Poreacutem esse ambiente adverso forccedilou a mudanccedila abrupta que gerou bons frutos para ainduacutestria dos JD Novos ninchos de mercados criados principalmente pelas accedilotildees de mer-

23


cado e produtos lanccedilados pela empresa Nintendo surgiram e uma nova abordagem foiempregada para o desenvolvimento de JD (RABIN 2012)

Embora seja possiacutevel encontrar diversas similaridades no processo de desenvolvimento deJD e de Sistemas Computacionais (SC) o ponto chave para encontrar a metodologia ouprocesso de desenvolvimento ideal para construccedilatildeo de JD estaacute justamente na identificaccedilatildeodas especificidades que estatildeo envolvidas na construccedilatildeo dos jogos (KEITH 2010 GODOYBARBOSA 2010 SALEN ZIMMERMAN 2012 SCHELL 2014)

As diferenccedilas se apresentam com clareza quando identificamos o conceito e a naturezados JD A definiccedilatildeo de Jogos Digitais apresentada em Garingsland (2011) diz que os JD satildeoespaccedilos de decisatildeo com regras recompensas e perda Esta definiccedilatildeo esta alinhada coma ideia de interaccedilatildeo que Crawford (1984) apresenta ao comparar a dinamicidade dos JDcom a linearidade das estoacuterias

Podemos fazer o mesmo paralelo entre os JD e os SC Conforme ilutrado na figura 23 osSistemas Computacionais apresentam uma seacuterie de eventos em sequecircncia dentro de umespaccedilo de tempo que sugere uma relaccedilatildeo de causa e efeito entre as suas funcionalidadesPor outro lado os JD possibilitam aos jogadores um conjunto de alternativas a cada to-mada de decisatildeo dentro do jogo Nos SC os usuaacuterios experimentam uma sequecircncia fixade eventos nos JD os jogadores satildeo encorajados a exploraacute-los (KEITH 2010 GODOYBARBOSA 2010 SALEN ZIMMERMAN 2012 SCHELL 2014)

Quando unimos a definiccedilatildeo de JD de Garingsland (2011) os conceitos de dinamicidade deinteraccedilatildeo e as perspectivas subjetiva e objetiva de Crawford (1984) o Ciacuterculo Maacutegico deHuizinga (1931) e a definiccedilatildeo de mecacircnica dos jogos construiacuteda nesta pesquisa poderemosobservar a natureza dinacircmica e exploratoacuteria dos Jogos Digitais A principal ideia que areuniatildeo desses conceitos apresenta eacute que os JD satildeo artefatos cujo conteuacutedo estaacute relacio-nado a comportamentos e experiecircncias que atendem os desejos e anseios dos jogadoresEssas caracteriacutesticas natildeo satildeo observadas nos SC e devido a isso classificamos os JD comoartefatos que transcendem o escopo dos SC (KEITH 2010)

24


Figura 23 Interaccedilatildeo entre usuaacuterios e os diferentes tipos de artefatos (EstoacuteriasSistemas Com-putacionais e Jogos Digitais) Fonte Adaptado de Crawford (1984)

As caracteriacutesticas peculiares do processo de desenvolvimento de JD exigiam uma formadiferente de abordagem (SCHELL 2014) Era preciso trabalhar em equipes e com focovoltado no talento e na criatividade para buscar inovaccedilatildeo e aumentar o valor do produtodesenvolvido todos os dias Foi com essa motivaccedilatildeo que a induacutestria de desenvolvimentode JD encontrou nas metodologias Aacutegeis a flexibilidade necessaacuteria para construir jogostrabalhando com equipes multidisciplnares livre de planejamentos e estimativas inafici-entes proacuteximo do cliente final e com processos voltados para o aprimoramento constantedo produto final (KEITH 2010 SUTHERLAND 2016)

242 O framework Scrum

A primeira coisa que devemos entender antes de comeccedilar a abordar o tema Scrum ilus-trado na Figura 24 eacute que natildeo iremos falar sobre uma metodologia Scrum eacute um fra-mework O Scrum natildeo eacute um conjunto de instruccedilotildees natildeo eacute algo pronto que iremos utilizarpara resolver algum problema ou construir um produto (DUARTE 2016) Uma boa formade idealizar o framework Scrum eacute pensar em uma estrutura baacutesica que seraacute utilizada paraconstruir algo A definiccedilatildeo formal apresentada pelos seus criadores diz que o Scrum eacute

Um framework dentro do qual pessoas podem tratar e resolverproblemas complexos e adaptativos enquanto produtiva e cri-ativamente entregam produtos com o mais alto valor possiacutevel(SCHWABER SUTHERLAND 2013)

Conforme ilustrado na Figura 24 a estrutura baacutesica do Scrum eacute enxuta e simples Elapossui um conjunto de eventos artefatos e personagens que viabilizam o desenvolvimentodo produto contando com o feedback quase que imediato do usuaacuterio final priorizando

25


as funcionalidades mais importantes dando foco agraves pessoas e ao produto final Essa eacutegrande diferenccedila do Scrum o processo eacute um meio natildeo um fim O objetivo maior eacute oproduto final (KEITH 2010)

Uma das caracteriacutesticas mais interessantes do Scrum estaacute no seu empirismo Esse fra-mework permite que seja possiacutevel trabalhar com a incerteza e a criatividade atraveacutes deuma estrutura que prioriza a aprendiagem permitindo a anaacutelise do que jaacute foi produzido e aforma que foi produzido Devido a isso o processo de desenvolvimento evolui com base nassuas experiecircncias passadas Esse processo de evoluccedilatildeo empiacuterica acontece devido agrave susten-taccedilatildeo de trecircs pilares transparecircncia inspeccedilatildeo e adaptaccedilatildeo (SUTHERLAND 2016) Outroaspecto muito importante do framework Scrum eacute o conceito de Timebox Todos os even-tos do Scrum (sprint planning daily scrum sprint review e sprint retrospective) possuemum tempo definido de duraccedilatildeo isso evita reuniotildees longas enfadonhas e improdutivas emanteacutem o foco dos participantes no objetivo principal da reuniatildeo (SUTHERLAND 2016)

Figura 24 Framework de desenvolvimento Scrum Fonte Adaptado de Sutherland (2016)

Antes de apresentar todos os artefatos eventos e o fluxo de trabalho do Scrum vamosidentificar os personagens que estatildeo direta e indiretamente relacionados com o ScrumIlustrados na Figura 25 observamos no canto superior esquerdo destacados em laranjaos stakeholder pessoas que satildeo importantes para o desenvolvimento de JD mas estatildeofora do Time Scrum Elas satildeo responsaacuteveis pela divulgaccedilatildeo vendas distribuiccedilatildeo finan-ciamento do projeto e relacionamento com os consumidores

Em verde no canto inferior direito os consumidores finais dos jogos digitais Eles satildeoa vaacutelvula de escape do mercado A linha de consumo deles tem influecircncia direta na cri-accedilatildeo e no pocesso de construccedilatildeo dos JD Alguns autores os coloca dentro da equipe dedesenvovimento (FULLERTON 2014) No centro destacados em vermelho estaacute o TimeScrum Ele eacute composto pelo Product Owner Scrum Master e Desenvolvedores Eles satildeoos responsaacuteveis diretos pela contruccedilatildeo dos JD Vamos detalhar um poucos mais as res-ponsabilidades de cada um deles

26


Figura 25 Personagens envolvidos no fluxo de trabalho do framework Scrum Fonte Adaptadode Sutherland (2016)

O Product Owner embora natildeo faccedila parte da equipe de Desenvolvedores eacute uma das figurascentrais do Scrum Ele eacute o responsaacutevel pelo contato entre o Time Scrum e as pessoas queestatildeo fora da equipe (stakeholders e consumidores) Devido a isso eacute ele quem possui oentendimento dos anseios e desejos do mercado e dos jogadores Ele eacute responsaacutevel porpassar para os Desenvolvedores todos os requisitos dos JD e precisa garantir o Retorno doInvestimento (ROI) feito pelos stakeholders As suas accedilotildees estatildeo relacionadas agrave definiccedilatildeode prioridades prazos e participaccedilatildeo das reuniotildees de planejamento (Sprint planning eSprint review) (KEITH 2010)

O Scrum Master eacute o responsaacutevel por garantir que o Time de Desenvolvedores siga aspraacuteticas do Scrum O trabalho dele estaacute relacionado a trecircs linhas de accedilotildees eliminar obs-taacuteculos que impedem o trabalho dos Desenvolvedores acompanhamento e alinhamento doatual estado do desenvolvimento atraveacutes de ferramentas de gestatildeo (artefatos) e encorajara equipe a sempre buscar melhoria contiacutenua Ele participa de todos eventos do Scrum(Sprint planning Daily scrum Sprint review e Sprint retrospective) e ajuda o ProductOwner na comunicaccedilatildeo do Time com os stakeholder (KEITH 2010 DUARTE 2016)

Os Desenvolvedores satildeo os responsaacuteveis pela implementaccedilatildeo do conjunto de itens queestatildeo definidos no backlog do Sprint Essa equipe eacute formada por um conjunto de profis-sionais que possuem as habilidades necessaacuterias para executar as tarefas planejadas Elestrabalham em equipe gerenciam o proacuteprio trabalho definem quantas funcionalidades po-dem entregar ateacute o final do Sprint e se comprometem a efetuar todo trabalho ateacute a data

27


planejanda (SUTHERLAND 2016)

O fluxo de trabalho do Scrum ilustrado na Figura 26 eacute iniciado com a reuniatildeo de plane-jamento do Sprint Sprint planning que geralmente tem a duraccedilatildeo de 8 horas Somenteos membro do Time Scrum participam dessa reuniatildeo O Product Owner apresenta alista de requisito dos JD product backlog ordenada por prioridade Os desenvolvedoresauxiliados pelo scrum master definem quantas funcionalidades eles podem implementardento do Sprint que geralmente tem a duraccedilatildeo de 3 a 4 semenas As funcionalidadesescolhidas definem o backlog do Sprint Sprint backlog que eacute o conjunto de itens que seratildeoimplementados no Sprint Aleacutem disso existe outro artefato muito imporante que eacute defi-nido ou atualizado na reuniatildeo de planejamento do sprint o documento de Definiccedilatildeo dePronto (Definition of Done - DOD) Ele conteacutem todos criteacuterios que seratildeo utilizados paradefinir se uma funcionalidade estaacute pronta Ele tembeacutem eacute feito com base na experiecircncia enecessidades dos Desenvolvedores

Depois que esses dois artefatos (Sprint backlog e DOD) estiverem prontos o Sprint eacuteiniciado Durante a execuccedilatildeo do Sprint diariamente no iniacutecio ou no fim do dia detrabalho uma reuniatildeo chamada Daily scrum deve acontecer Ela tambeacutem eacute conhecidacomo Reuniotildees diaacuterias Daily Meeting Stand-Up Meeting e Daily Stand-Up Ela eacute bemcurta 15 minutos no maacuteximo e todos participantes devem estar de peacute Isso garante queela seja objetiva e raacutepida Somente os Desenvolvedores e o Scrum Master participam delaNesta reuniatildeo cada desenvolvedor deve responder trecircs perguntas O que eu fiz ontemO que eu farei hoje e Existe algum impedimento que atrapalhe o desenvolvimento domeu trabalho A Daily scrum eacute um meacutetodo eficaz de manter o alinhamento entre osmembro do Time e permite que problemas e desvios sejam rapidamente descobertos Eladeve ser realidazada sempre no mesmo local e horaacuterio para entrar na rotina diaacuteria dosDesenvolvedores Ela precisa ser respeitada e executada diariamente (DUARTE 2016)

28


Figura 26 Eventos e artefatos do framework de desenvolvimento Scrum Fonte Adaptado deSutherland (2016)

No final de cada Sprint o produto ou incremento desenvolvido eacute apresentado ao ProductOwner e aos stakeholders em uma reuniatildeo chamada Sprint Review Essa reuniatildeo deaproximadamente 4 horas de duraccedilatildeo eacute o evento de inspeccedilatildeo mais importante Eacute nestareuniatildeo que o cliente final daacute um feedback do produto que estaacute sendo desenvolvido Todasinformaccedilotildees e criacuteticas feitas pelo Product Owner e pelos stakeholders satildeo utilizadas pararefazer o product backlog e aperfeiccediloar o JD em desenvolvimento

O uacuteltimo evento do ciclo de desenvolvimento do Scrum eacute o Sprint Retrospective Nestareuniatildeo de aproximadamente 3 horas de duraccedilatildeo a equipe de Desenvolvimento e o ScrumMaster falam sobre os resultados obtidos no Sprint evidenciam e discutem as liccedilotildeesaprendidas e apresentam as accedilotildees que devem ser tomadas para melhorar o processo dedesenvolvimento Essa reuniatildeo contribui muito para a adaptaccedilatildeo do Scrum agrave realidadedo projeto O grande desafio dessa reuniatildeo eacute apresentar accedilotildees exequiacuteveis para evitar queos problemas reapareccedilam (SUTHERLAND 2016)

Para sumarizar o nosso entendimento sintetizamos os eventos artefatos e os trecircs pilaresque sustentam o framework de desenvolvimento Scrum na tabela 22 Ela apresenta a re-

29

Capiacutetulo Dois 25 Definindo os requisitos de um Jogo Digital

laccedilatildeo que existe entres os eventos Scrum os artefatos utilizados em cada um dos eventose a relaccedilatildeo que eles tecircm com uma das sustentaccedilotildees ideoloacutegicas do Scrum Vale ressaltarque mesmo sem apresentar o pilar transparecircncia na referida tabela o viacutenvulo que existeentre os componentes Scrum cria um ciclo que se retroalimenta Ou seja as accedilotildees deinspeccedilatildeo impulsionam as adaptaccedilotildees do processo de desenvolvimento que por sua vezevidencia a necessidade de transparecircncia e o trabalho em grupo

Evento Inspeccedilatildeo Adaptaccedilatildeo

Sprint planning- Backlog do produto- Acordos da retrospectiva- Definiccedilatildeo de pronto

- Sprint goal- Sprint backlog- Novidades

Daily Scrum - Progresso do Sprint goal - Sprint backlog- Daily scrum

Sprint Review- Incremento do produto- Backlog do produto- Anaacutelise do mercado

- Backlog do Produto

Sprint Retrospective- Colaboraccedilatildeo do time- Teacutecnicas e tecnologias- Definiccedilatildeo de pronto

- Adaptaccedilotildees no processo

Tabela 22 Objetivos dos eventos no Scrum Adaptado de Schwaber amp Sutherland (2013) Keith(2010)

25 Definindo os requisitos de um Jogo Digital

Definir os requisitos de um JD eacute uma atividade bastante semelhante agrave construccedilatildeo dos re-quisitos de um Sistema Computacional (FILHO et al 2013) Podemos definir requisitosutilizando o conjunto de documentos de anaacutelise de requisitos como Casos de Uso e Diagra-mas UML (caso de uso classes objetos colaboraccedilatildeo sequecircncia atividades e outros)Emempresas que possuem processos de desenvolvimento com baixo grau de maturidade essaatividade eacute feita ateacute por e-mail (SOMMERVILLE 2010) Neste trabalho iremos focar anossa atenccedilatildeo em duas teacutecnias bem aplicadas e utilizadas para definir requisitos de JDas user stories e a prototipaccedilatildeo (KEITH 2010 FILHO et al 2013)

As user stories satildeo pequenos documentos que possuem descriccedilotildees curtas de desejos neces-sidades ou caracteriacutesticas que um usuaacuterio espera encontrar em um sistema Elas possuemuma estrutura baacutesica ilustrada da Figura 27 que apresenta o ator que a solicitou amotivaccedilatildeo o tamanho e os benefiacutecios que o conteuacutedo proporciona aos usuaacuterios (SCHE-TINGER et al 2011) Essa estrutura baacutesica simples e direta permite que pessoas quenatildeo possuem experiecircncia com o desenvolvimento de JD possam se comunicar com a equipede desenvolvimento atraveacutes das user stories Esse fato eacute importante porque possibilitao contato direto com o usuaacuterio final o consumidor dos JD e com as pessoas que satildeo

30


responsaacuteveis pela construccedilatildeo de cenaacuterios que iratildeo imergir o jogador na experiecircncias do JD(KEITH 2010)

Figura 27 Estrutura de uma user storie Fonte Adaptado de Keith (2010)

A segunda teacutecnica bem aplicada para definiccedilatildeo de requisitos para construccedilatildeo de JD satildeoos protoacutetipos (FILHO et al 2013) Os protoacutetipos satildeo modelos que tecircm o objetivo devalidar e concretizar as ideias que estatildeo sendo desenvolvidas durante a produccedilatildeo Elespodem ser generalizados em dois tipos o conceitual e o fiacutesico ilustrados na Figura 28 Oprotoacutetipo conceitual geralmente eacute bem distante do produto final ele objetiva estabelecero funcionamento e comportamento do produto Por outro lado o protoacutetipo fiacutesico queno ambiente de desenvolvimento de JD eacute chamado de protoacutetipo funcional ou Build temcaraacuteter mais voltado para validaccedilatildeo e tende a se aproximar do produto final agrave medida queos ciclo de desenvolvimento ou Sprints satildeo terminados (SHARP ROGERS PREECE2005 KEITH 2010 SCHELL 2014)

Figura 28 Agrave esquerda o protoacutetipo conceitual e agrave direita o protoacutetipo funcionalDois tipos deprotoacutetipo segundo Sharp Rogers amp Preece (2005) Agrave esquerda o protoacutetipo conceitual e agrave direitao protoacutetipo funcional Fonte Pinterest (2010)

A junccedilatildeo dessas duas teacutecnicas possibilitam agrave equipe de desenvolvimento uma comunicaccedilatildeo

31


simples direta e eficiente com os seus clientes e com os jogadores os usuaacuterios finais dosJD aleacutem de proporcionar economia de recursos como dinheiro dos stakeholders e tempodos desenvolvedores (SHARP ROGERS PREECE 2005 KEITH 2010 FILHO et al2013 SCHELL 2014)

Um exemplo da junccedilatildeo de teacutecnicas incluindo as user stories e a prototipaccedilatildeo para aprimo-rar a definiccedilatildeo de requisitos eacute o Google Sprint ilustrada na Figura 29 Essa metodologiacriada pela GV (Google Ventures) empresa da Google com o foco voltado para o empre-endedoresimo e teste de ideias inovadoras possui cinco fases (Entendimento Esboccedilo De-finiccedilatildeo Prototipaccedilatildeo e Validaccedilatildeo) que devem ser executadas em cinco dias (Segunda-feiraTerccedila-feira Quarta-feira Quinta-feira e Sexta-feira) (KNAPP ZERATSKY KOWITZ2016)

Figura 29 Agrave esquerda visualizamos o processo geral das etapas de lanccedilamento de um produtoAgrave direita apresentamos as cinca etapas da metodologia Google Sprint Etapas da metodologiaGoogle Sprint Agrave esquerda visualizamos o processo geral das etapas de lanccedilamento de umproduto Agrave direita apresentamos as cinca etapas da metodologia Google Sprint Fonte KnappZeratsky amp Kowitz (2016)

Contudo devemos ressaltar que a metodologia Google Sprint natildeo eacute bem aplicada paratodo o processo de desenvolvimento de um JD Afirmamos isso porque da mesma formaque acontece na metodologia Cascata (ROYCE 1970) todo planejamento da metodologiaGoogle Sprint eacute efetivado no iniacutecio do processo Poreacutem conforme jaacute dito anteriormentea incerteza e o aprendizado satildeo caracteriacutesticas intriacutensecas ao processo de desenvolvimentode JD de meacutedio ou grande porte Devido a isso JD de maior porte precisam de diversosciclos de planejamento desenvolvimento e aperfeiccediloamento para atender agraves demandas eanseios dos jogadores (SCHELL 2014)

32

Capiacutetulo Dois 26 Instrumentalizaccedilatildeo

26 Instrumentalizaccedilatildeo

Nesta seccedilatildeo apresentaremos os modelos protocolos metodologias e praacuteticas utilizadaspara construccedilatildeo do modelo que define o processo de desenvolvimento de JD Durante essainvestigaccedilatildeo encontramos diversas publicaccedilotildees que poderiam ser aplicadas para definiccedilatildeodo modelo que explica o funcionamento do processo de construccedilatildeo de JD e das sugestotildeesde adaptaccedilatildeo no framework Scrum que fizemos nesta obra Dentre elas podemos citarBartle (2004) LeBlanc et al (2004) Schell (2014) McGonigal (2011) Salen amp Zimmer-man (2012) Chou (2015) Beck (2009) Poppendieck amp Poppendieck (2009)

Enretanto optamos por publicaccedilotildees com caracteriacutesticas estruturantes para que o nossomodelo adquirisse as propriedades de um framework que define o que devemos fazer paraconstruir JD natildeo como devemos fazer Devido a isso escolhemos as seguintes obrasGrimm et al (2006) Grimm et al (2010) Werbach amp Hunter (2012) e Hunicke LeBlancamp Zubek (2004)

27 O protocolo ODD

O ponto de partida para construccedilatildeo do nosso modelo eacute o protocolo ODD (Overview De-sign concepts e Details) (GRIMM et al 2006) Esse protocolo foi proposto para descreverModelos Baseados em Indiviacuteduos (IBM) Poreacutem antes de iniciar a apresentaccedilatildeo do pro-tocolo acima citado precisamos entender dois conceitos que impulsionaram a necessidadedo desenvolvimento do ODD modelos e IBM

Um modelo eacute uma representaccedilatildeo de algum sistema real ou de uma abstraccedilatildeo conceitual eo principal motivo que nos impulsiona a construir modelos eacute a possibilidade de estudar deforma efetiva e detalhada como eles se comportam quando satildeo submetidos a mudanccedilas(STARFIELD 1990) Um bom exemplo da aplicaccedilatildeo de modelos eacute o estudo do desenvol-vimento de cidades Os paracircmetros necessaacuterios para analisar a evoluccedilatildeo de uma cidadesatildeo tatildeo diversos e se modificam em uma escala tatildeo pequena que seria praticamente impos-siacutevel estudar esse evento de forma empiacuterica e experimental Poreacutem utilizando um modelocomputacional eacute possiacutevel emular o desenvolvimento da cidade analisando as modificaccedilotildeesdos paracircmetros em diferentes escalas e a partir desses dados estudar desenvolvimento domodelo (RAILSBACK GRIMM 2011)

A definiccedilatildeo claacutessica define IBM como modelos que descrevem entidades individuais e autocirc-

33

Capiacutetulo Dois 27 O protocolo ODD

nomas (DEANGELIS GROSS 1992) Poreacutem o grande problema dessa definiccedilatildeo eacute queela natildeo diferencia os IBM dos outros modelos Para solucionar esse problema Uchmańskiamp Grimm (1996) criaram quatro paracircmetros que caracterizam os IBM diferenciando-osdos outros modelos Os quatro paracircmetros satildeo (1) grau de complexidade do ciclo devida do agenteindiviacuteduo no modelo (2) dinacircmica de utilizaccedilatildeo dos recursos por parte doagenteindiviacuteduo (3) representaccedilatildeo do nuacutemero de agenteindiviacuteduo na populaccedilatildeo e (4)variedade de agenteindiviacuteduo da mesma idade na populaccedilatildeo

O grau de complexidade do ciclo de vida representa as mudanccedilas que um indiviacuteduo sofreno decorrer de sua vida Geralmente as necessidade de consumo muda a capacidade dereproduccedilatildeo diminui e a capacidade de se adaptar ao ambiente eacute reduzida A dinacircmica deutilizaccedilatildeo dos recursos caracteriza as necessidades da populaccedilatildeo de indiviacuteduos e os dife-rentes tipo de recursos dispostos no ambiente A representaccedilatildeo do nuacutemero de indiviacuteduosilustra o crescimento ou diminuiccedilatildeo da populaccedilatildeo de acordo com as taxas de natalidade emortalidade do sistema E por fim a variedade de agentes da mesma idade representa aindividualizaccedilatildeo do agente Esse paracircmetro possibilita a criaccedilatildeo de indiviacuteduos uacutenicos napopulaccedilatildeo diferenciados pelas suas propriedades (UCHMAŃSKI GRIMM 1996)

Embora a utilizaccedilatildeo e aplicaccedilatildeo de IBM fosse diversa e a natureza desse tipo particularde modelo fosse mais complexa natildeo existia um protocolo que padronizasse a descriccedilatildeodesse tipo de modelo Devido a isso a definiccedilatildeo de modelos baseados em indiviacuteduos erafeita de forma verbal detalhes matemaacuteticos e a concepccedilatildeo estrutural dos modelos eramapresentada atraveacutes de longos textos fato que dificultava o entendimento e a reproduccedilatildeodos IBM E eacute essa lacuna que o ODD se propotildee a preencher Ele simplifica a leitura eo entendimento da descriccedilatildeo dos IBM o que facilita o desenvolvimento a atualizaccedilatildeo eproporciona uma maior credibilidade cientiacutefica aos IBM Eacute justamente por causa dessacaracteriacutestica que noacutes escolhemos o ODD para ser uma das bases estruturantes do nossomodelo Conforme ilustrado na Figura 210 o ODD eacute composto por trecircs blocos principaisque satildeo subdivididos em sete (GRIMM et al 2006)

Figura 210 Estrutura do protocolo ODD Fonte Adaptado de Grimm et al (2006)

34


O bloco Visatildeo geral eacute composto por trecircs elementos (propoacutesito variaacuteveis de estado eescala e visatildeo do processo e escalonamento) e tem como objetivo passar para o leitor avisatildeo geral e a finalidade do modelo dando a ele a noccedilatildeo de complexidade dos agentesque seratildeo implementados Propoacutesito eacute o primeiro bloco de detalhamento do protocoloODD Ele conteacutem o motivo pelo qual o modelo que seraacute descrito precisa ser construiacutedoAleacutem disso ele apresenta as informaccedilotildees baacutesicas sem as quais o leitor natildeo vai entender osprinciacutepios fundamentais do modelo

As variaacuteveis de estado e escala satildeo o conjunto de variaacuteveis mais importantes do modelosElas descrevem informaccedilotildees de configuraccedilatildeo do ambiente e caracterizam os agentes quefazem parte do sistema A apresentaccedilatildeo dessas variaacuteveis deve ser clara e direta evitandoa necessidade de deduccedilotildees O uacuteltimo elemento do bloco Visatildeo Geral eacute a visatildeo do processoe escalonamento Ele descreve de forma direta e verbal sem usar formalismos matemaacuteti-cos os conceitos que seratildeo implementados em cada processo do modelo Nesta etapa eacutemuito comum utilizar diagramas para facilitar a visualizaccedilatildeo do fluxo das informaccedilotildees ea execuccedilatildeo dos processos

O bloco Conceitos de projeto apresenta o esqueleto do modelo que seraacute construiacutedo Eleconteacutem a descriccedilatildeo de todas as questotildees funcionais dos aspectos comportamentais e dosesquemas de comunicaccedilatildeo do modelo Os meacutetodos matemaacuteticos que seratildeo implementadosno modelo tambeacutem satildeo apresentados nesta seccedilatildeo mas o formalismo matemaacutetico natildeo eacuteexposto neste momento

Por fim a bloco Detalhes Ele tambeacutem eacute composto por trecircs elementos (inicializaccedilatildeo en-trada e submodelos) e tem o objetivo de apresentar todos os detalhes que foram omitidosnas seccedilotildees anteriores Na seccedilatildeo inicializaccedilatildeo satildeo definidos os valores iniciais do sistema edo ambiente As variaacuteveis descritas na seccedilatildeo variaacuteveis de estado e escala recebem os seusvalores iniciais

O bloco entrada eacute um dos mais importante do protocolo Os IBM estatildeo imersos em am-biente computacional que conteacutem outros agentes e uma seacuterie de variaacuteveis e equaccedilotildees quesimulam as condiccedilotildees desse ambiente Devido a isso os dados que entram e saem doambiente e dos IBM satildeo extremamente dinacircmicos Todas as relaccedilotildees de entrada e saiacutedade dados do ambiente e dos IBM devem ser minuciosamente descritas nesta seccedilatildeo

O bloco submodelos conteacutem todos os detalhes e especificaccedilotildees matemaacuteticas do modelo

35


As explicaccedilotildees que outrora foram verbais nos blocos anteriores aqui ganham detalhesGeralmente essa seccedilatildeo eacute matematicamente densa Os proacuteprios autores Grimm et al (2010)sugerem que sejam utilizadas equaccedilotildees e regras matemaacuteticas dispostas em tabelas parafacilitar o entendimento do modelo E se isso natildeo for possiacutevel o autor recomenda queessas explicaccedilotildees sejam feitas em outra publicaccedilatildeo

Quatro anos apoacutes a sua publicaccedilatildeo o protocolo ODD foi atualizado A nova publicaccedilatildeodo protocolo tinha o objetivo de aperfeiccediloar e esclarecer alguns pontos do ODD que invi-abilizaram a descriccedilatildeo de alguns modelos de IBM Conforme ilustrado na Figura 211 asmudanccedilas apresentadas na nova versatildeo do protocolo ODD foram sutis apenas 25 daspublicaccedilotildees que utilizaram o ODD se equivocaram durante a descriccedilatildeo dos seus modelosporeacutem essas falhas foram essenciais para garantir o valor do ODD perante a comunidadecientiacutefica (GRIMM et al 2010)

Aleacutem de modificar o nome de dois elementos (o bloco Variaacuteveis de estado e escala passoua se chamar Entidades variaacuteveis de estado e escala e o bloco Entrada passou a se cha-mar Entrada de dados) o bloco Conceitos de projeto ganhou dois elementos (princiacutepiosbaacutesicos e aprendizagem) e sofreu a alteraccedilatildeo de um dos seus elementos (o elemento Metapassou a se chamar Objetivo) Aleacutem disso todos os blocos e elementos que compotildeem oprotocolo ODD foram explicados detalhadamente para dirimir todas as possibilidades deequiacutevocos

36

Capiacutetulo Dois 28 A piracircmide de elementos da gamificaccedilatildeo

Figura 211 Em amarelo destacam-se as diferenccedilas entre as duas versotildees do protocolo Compa-raccedilatildeo entre as duas versotildees do protocolo ODD Em amarelo destacam-se as diferenccedilas entre asduas versotildees do protocolo Fonte Adaptado de Grimm et al (2010)

28 A piracircmide de elementos da gamificaccedilatildeo

O Segundo modelo que utilizamos como base estruturante do nosso modelo eacute a piracircmidede Werbach amp Hunter (2012) Esse modelo foi construiacutedo para facilitar a introduccedilatildeo eo desenvolvimento de atividades e produtos que utilizam a gamificaccedilatildeo com o objetivoaumentar o engajamento dos recursos humanos da empresa e de seus clientes

A formalizaccedilatildeo conceitual mais aceita sobre a gamificaccedilatildeo afirma que gamificar consisteem utilizar a mecacircnica dos jogos em atividades que natildeo estatildeo dentro do contexto dosjogos (DETERDING et al 2011) Essa abordagem muda completamente a forma deconstruccedilatildeo das atividades porque neste caso o foco das atividades satildeo as pessoas osaspectos motivacionais a participaccedilatildeo e o envolvimento dos sujeitos no processo Destaforma os elementos da mecacircnica dos jogos (desafio objetivos niacuteveis sistema de feedbacke recompensa) satildeo utilizados para criar situaccedilotildees que mobilizam e engajam os sujeitospara a realizaccedilatildeo de tarefas (MCGONIGAL 2011) Para se ter uma ideia mais precisado alcance da gamificaccedilatildeo apresentaremos um exemplo concreto da aplicaccedilatildeo dessa me-todologia

Em 2010 pesquisadores da Universidade de Washington utilizaram o jogo Foldit paraentender o funcionamento e o comportamento de uma determinada proteiacutena que poderia

37


ser utilizada no combate ao viacuterus da AIDS Esta iniciativa conseguiu contar com a coo-peraccedilatildeo de 46 mil participantes com experiecircncia em diferentes aacutereas do conhecimento emuitos deles em aacutereas distantes da medicina O esforccedilo de trabalho desse grupo resolveuem apenas 10 dias o problema que os pesquisadores da aacuterea trabalhavam haacute mais de 15anos sem sucesso (KHATIB et al 2011)

Para facilitar o entendimento da tecircnue fronteira que existe entre os jogos as atividadesgamificadas e os outros conceitos que estatildeo intrinsecamente relacionados a eles utiliza-remos o diagrama ilustrado na Figura 212 de Deterding et al (2011) Neste diagramaestatildeo representados no eixo horizontal os elementos dos jogos (em amarelo) e o jogocompleto (em vermelho) No eixo vertical representamos o formalismo de um jogo (emazul) e a liberdade de uma brincadeira (em branco) Os conceitos de jogos gamificaccedilatildeobrincadeira e design luacutedico satildeo representados com as cores criadas a partir da junccedilatildeo deduas cores dos eixos horizontal e vertical

De acordo com a Figura 212 a gamificaccedilatildeo representada pela cor verde surge a partirda uniatildeo do formalismo e dos os elementos dos jogos Eacute sobre o equiliacutebrio entre essasduas forccedilas que as atividades gamificadas bem projetadas se sustentam No quadrante aolado estatildeo os jogos seacuterios que satildeo conceitualmente concebidos pela junccedilatildeo do formalismodos jogos e de todos os elementos baacutesicos que formam um jogo Na parte inferior dodiagrama estatildeo conceitos que estatildeo essencialmente libertos de regras e estruturas riacutegidas- o formalismo natildeo se aplica a eles Os conceitos de brinquedo e design luacutedico satildeo livrese imbuiacutedos de muita experimentaccedilatildeo (DETERDING et al 2011)

38


Figura 212 Relaccedilatildeo entre jogos gamificaccedilatildeo brinquedos e designer luacutedico Fonte Adaptadode Deterding et al (2011)

Conforme apresentado anteriormente Werbach amp Hunter (2012) usam o termo PBL(Points Badges e Leaderboards) para se referir aos elementos da gamificaccedilatildeo mais co-muns (pontos medalhas e tabelas de posicionamento) e utilizam-nos como ponto de par-tida para construccedilatildeo de uma estrutura hieraacuterquica que alicerccedila a criaccedilatildeo de estrateacutegiasgamificadas A grande vantagem que essa estrutura oferece estaacute no caminho que ela criaatraveacutes da associaccedilatildeo direta entre os elementos das diferentes categorias fato que diminuia possibilidade de erros e manteacutem o foco da estrateacutegia gamificada voltada para a soluccedilatildeodo problema ou criaccedilatildeo da atividade A piracircmide de elementos de gamificaccedilatildeo ilustradana figura 213 agrupa uma seacuterie de elementos organizados de forma decrescente em trecircscategorias dinacircmica mecacircnica e componentes

Figura 213 Piracircmide de elementos de gamificaccedilatildeo Fonte Adaptado de Werbach amp Hunter(2012)

39


A categoria dinacircmica agrupa os elementos mais conceituais de um jogo Eacute nesta categoriaque estatildeo os suportes que implicitamente estruturam o jogo e as estrateacutegias de gamifi-caccedilatildeo Aqui satildeo definidos fatores limitantes do jogo como nuacutemero de jogadores tempomaacuteximo de cada jogada e quantidade de vidas de um jogador a narrativa que ambien-taliza e emerge ludicamente os jogadores e por fim a forma de relacionamento entre osjogadores que muitas vezes varia entre a competiccedilatildeo e a cooperaccedilatildeo

A segunda categoria a mecacircnica estaacute diretamente relacionada agraves accedilotildees que podem acon-tecer durante o jogo Elas satildeo as forccedilas que guiam os jogadores dentro do ambiente dejogo Aqui satildeo agrupados os desafios competiccedilotildees accedilotildees cooperativas e todas as ativi-dades que os jogadores vivenciam dentro do jogo Neste ponto vale a pena chamar aatenccedilatildeo para o conceito de regra Na piracircmide de elementos de gamificaccedilatildeo de Werbachamp Hunter (2012) as regras do jogo natildeo estatildeo declaradamente dentro de uma categoriaelas estatildeo impliacutecitas nas definiccedilotildees das estrateacutegias de gamificaccedilatildeo e das accedilotildees de jogo

A categoria componentes armazena os elementos que concretizam os conceitos definidosna dinacircmica e mecacircnica do jogo Satildeo elementos primitivos com os quais os jogadores iratildeointeragir diretamente Satildeo eles os pontos medalhas tabelas de posicionamento niacuteveisavatares dentre outros Outro ponto muito importante que devemos ressaltar na piracircmidede elementos de gamificaccedilatildeo de Werbach amp Hunter (2012) eacute a relaccedilatildeo que existe entreos elemento das trecircs categorias Os elementos da categoria dinacircmica estatildeo relacionadoscom os elementos da categoria mecacircnica Da mesma forma os elementos da categoriamecacircnica estatildeo relacionados aos elementos dos componentes

Para alcanccedilar um melhor entendimento sobre a relaccedilatildeo entre os elementos das categoriasda piracircmide de elementos de gamificaccedilatildeo de Werbach amp Hunter (2012) apresentamos naTabela 23 os elementos de PBL utilizando os JD da trilogia Mass Effect relacionando-oscom as categorias da piracircmide de elementos de gamificaccedilatildeo

40

Capiacutetulo Dois 29 O modelo MDA

Componentes Mecacircnica DinacircmicaItens Satildeo objetos que os jogado-

res ganham ou encontram du-rante o jogo como armas dis-positivos eletrocircnicos coacutedigossenhas armaduras mineraiscombustiacutevel

Os jogadores utilizam os itenspara obter alguma vantagemcomo por exemlo causar maisdano aos oponentes acessaraacutereas especiais e atingir o ob-jetivo com maior facilidade

Pontos O jogador ganha pontosquando realiza uma accedilatildeonobre (paladino) ou quandotoma alguma decisatildeo maisfria e calculista (renegado)

A moral do jogador (paladinoou renegado) possibilita dife-rentes espaccedilos de decisatildeo Issopode tornar o jogo mais difiacutecilou faacutecil

Niacuteveis Um conjunto de missotildees eacute pas-sado ao jogador (divisatildeo doobjetivo principal do jogo)dando ao jogador desafios pro-gressivos e condizentes com assuas habilidade

Em cada niacutevel o jogador en-contra diferentes motivaccedilotildeespara aumentar a capacidadede combate de sua tripulaccedilatildeo

Medalhas Satildeo insiacutegnias dadas ao jogadorquando ele realiza um grupode tarefas especiacuteficas duranteo jogo

As medalhas destacam o jo-gador dentro dos ciclos sociaisque ele frequenta (redes soci-ais foacuteruns sites etc)

Tabela 23 Elemento de PBL da trilogia Mass Effect e suas relaccedilotildees com as categorias dapiracircmide de elementos de gamificaccedilatildeo de Werbach amp Hunter (2012)

Contudo devemos ressaltar que a piracircmide de elementos de gamificaccedilatildeo de Werbach ampHunter (2012) natildeo cobre a totalidade do assunto gamificaccedilatildeo Ela constroacutei uma associa-ccedilatildeo direta entre os elementos dos jogos e possibilita a construccedilatildeo eficiente de atividadesgamificadas relacionando os princiacutepios mais elementares (os componentes) com as regrasque seratildeo utilizadas nas atividades (a mecacircnica) e as estrateacutegias que proporcionam o en-gajamento dos usuaacuterios (a dinacircmica da atividade) Fora das fronteiras desse modelo estaacutea experiecircncia e esteacutetica de jogo provocada pela atividade gamificada

29 O modelo MDA

O Terceiro e uacuteltimo modelo estruturante utilizado neste trabalho foi o MDA (MechanicsDynamics and Aesthetics) (HUNICKE LEBLANC ZUBEK 2004) Esse modelo foi cri-ado com o objetivo de diminuir as lacunas e fortalecer a interaccedilatildeo entre os desenvolvedoresde JD (artistas e programadores) e os usuaacuterios (jogadores criacuteticos e a comunidade acadecirc-mica) Existem diversas metodologias para construccedilatildeo de JD elas apresentam diferenteselementos que independente da plataforma satildeo importantes para o desenvolvimento deum jogo digital ou analoacutegico (MASTROCOLA 2015) Poreacutem a falta de experiecircnciateacutecnica dos usuaacuterios finais os fazem pensar que os diferentes tipo de jogos satildeo construiacutedos

41


da mesma forma O MDA corrige essa distorccedilatildeo e traz a possibilidade de avaliar os jogosindependente do seu tipo ou plataforma (HUNICKE LEBLANC ZUBEK 2004) Paradeixar clara a importacircncia do MDA faremos uma reflexatildeo sobre um modelo que defineos elementos baacutesicos que estatildeo evolvidos no processo de desenvolvimento de JD

Schell (2014) em sua obra The Art of Game Design A book of lenses apresenta os cincoelementos ilustrados na Figura 214 que norteiam o processo de desenvolvimento de umJD Ela apresenta destacado em azul os elementos do processo cujo foco estatildeo voltadospara o jogo Em verde destacam-se os elementos focados no jogador e em vermelho oelemento responsaacutevel pela concepccedilatildeo do JD e das estrateacutegias gamificadas

Figura 214 Em azul destacam-se os elementos do processo focados no jogo em verde destacam-se os elementos focados no jogador e em vermelho o elemento responsaacutevel pela concepccedilatildeo epelas estrateacutegias gamificadas Fonte Adaptado de Schell (2014)

O Game Designer eacute um profissional que tem uma funccedilatildeo central no processo de desen-volvimento de um jogo digital Ele trabalha com um grupo de especialistas ou sozinhoem um projeto pequeno que desenvolvem as estrateacutegia que iratildeo produzir a experiecircnciade jogo que seraacute vivenciada pelo jogador Aleacutem de ser responsaacutevel pelo desenvolvimentoe pelo sucesso do jogo ele efetua funccedilotildees administrativas lidando com prazos documen-taccedilatildeo e clientes Esse profissional naturalmente tem muitas habilidades poreacutem a maisimportante eacute saber ouvir a sua equipe e os jogadores que estatildeo testando o jogo e o seupuacuteblico-alvo A compreensatildeo dos anseios das pessoas que opinam sobre o jogo aproximao game designer da experiecircncia que ele deseja transmitir ao jogador

O elemento Processo refere-se agrave metodologia utilizada para construccedilatildeo do game Schell

42


(2014) utiliza o processo chamado design iterativo ilustrado na Figura 215 Um meacutetodoque realiza testes constantes no produto que estaacute em processo de desenvolvimento e pri-oriza a construccedilatildeo de protoacutetipos para aprimorar as ideias e conceitos criados pelo GameDesigner

Figura 215 Fases do design iterativo Fonte Adaptado de Schell (2014)

A base conceitual dessa metodologia de desenvolvimento estaacute no modelo espiral de desen-volvimento de software (BOEHM 1988) O design iterativo possui trecircs pontos baacutesicosanaacutelise de riscos prototipaccedilatildeo e loop (repeticcedilatildeo) Em linhas gerais durante o loop deiteraccedilatildeo vocecirc executa as seguintes atividades (SCHELL 2014)

bull Apresentar as ideias baacutesicas do design

bull Construir um protoacutetipo para analisar os riscos

bull Testar o protoacutetipo

bull Aprimorar o design com a experiecircncia aprendida

bull Retornar ao passo 2

O Game eacute o momento no qual a equipe de programadores trabalham na construccedilatildeoefetiva do jogo Personagens objetivos procedimentos fases desafios regras recursosartefatos e as limitaccedilotildees do jogo comeccedilam a ser materializados Os protoacutetipos satildeo cria-dos testados analisados e aperfeiccediloados ateacute alcanccedilar o grau de maturidade e ludicidadeidealizados pela equipe do projeto

Player eacute uma etapa que estaacute em execuccedilatildeo constantemente Nela satildeo efetuadas pesquisaspara precisar o perfil dos jogadores que o JD vai atender Geralmente os Game Designerscategorizam os jogadores por grupos para classificar os seus anseios Schell (2014) agrupa

43


os jogadores por gecircnero (masculino e feminino) devido aos diferentes interesses que exis-tem entre homens e mulheres e por faixa de idade (noves grupos que satildeo iniciados comcrianccedilas de 3 anos ateacute adultos com mais de 50 anos) por causa das limitaccedilotildees de assuntose temas que a idade impotildee aos jogadores Aleacutem disso a faixa de idade tem um influecircnciadireta na mecacircnica e na jogabilidade do JD

A Experiecircncia do jogador eacute a razatildeo principal do trabalho do Game Designer Os JDnos proporcionam experiecircncias memoraacuteveis devido ao impacto direto que eles tecircm sobreos aspectos cognitivos sociais e emocionais dos jogadores (MCGONIGAL 2011 ALVES2012 GEE 2003) Como existe um grande nuacutemero de aacutereas das ciecircncias que exploramos segredos da mente humana Schell (2014) investiga trecircs ramos do conhecimento paraconstruir experiecircncias para os jogadores a psicologia para entender a mente humana aantropologia para entender o comportamento humano e o designer para construir expe-riecircncias prazerosas

A uniatildeo dos cinco elementos apresentados por Schell (2014) e ilustrado na Figura 214acontece de forma fluida no desenvolvimento de JD devido a duas caracteriacutesticas metodo-logia e a interdisciplinaridade As metodologias iterativas de desenvolvimento possibilitamque o produto idealizado pelo Designer seja avaliado em duas direccedilotildees O resultado finalpode aperfeiccediloar a implementaccedilatildeo e a implementaccedilatildeo eacute capaz de refinar o produto finalEssa peculiaridade eacute muito importante especialmente quando estamos trabalhando comJD Esses artefatos propiciam manifestaccedilotildees de comportamentos complexos que devemser estudados antes de o JD ser construiacutedo fato que exige uma equipe multidisciplinare proximidade entre desenvolvedores e jogadores (HUNICKE LEBLANC ZUBEK 2004)

Outra caracteriacutestica relevante estaacute na forma como a equipe de desenvolvimento vai tra-balhar O foco eacute nunca perder de vista o link entre as diferentes aacutereas do conhecimentoA natureza multidisciplinar da equipe pode se perder durante o processo de desenvolvi-mento porque muitas vezes eacute necessaacuterio focar a atenccedilatildeo na sua aacuterea de conhecimentoDevido a isso detalhes e aspectos importantes de outras aacutereas satildeo ignorados Essa fatoeacute indesejado durante a construccedilatildeo e concepccedilatildeo de um JD devido ao propoacutesito maior daequipe de multidisciplinar O grupo precisa trabalhar de forma cooperativa considerandoquestotildees fora da sua aacuterea de conhecimento (HUNICKE LEBLANC ZUBEK 2004 SA-LEN ZIMMERMAN 2012)

Eacute justamente neste ponto que a proposta apresentada pelo MDA se mostra importante(HUNICKE LEBLANC ZUBEK 2004) Esse modelo possibilita a utilizaccedilatildeo coerente de

44


elementos dos JD que aparentemente satildeo vistos como contraditoacuterios atraveacutes do enten-dimento dos seus conceitos analisados a partir da visatildeo do Designer e do jogador Essanecessidade surge da diferenccedila que existe entre os JD e as outras miacutedias voltadas parao entretenimento como livros e viacutedeos Os JD natildeo satildeo lineares natildeo eacute possiacutevel prever asequecircncia de eventos que iratildeo acontecer durante uma partida O jogador determina o seucaminho dentro do game (HUNICKE LEBLANC ZUBEK 2004)

No MDA os elementos dos jogos satildeo agrupados em trecircs componentes Regras Sistemase Diversatildeo Esses componentes possuem contrapostos que os relacionam com o designMecacircnica Dinacircmica e Esteacutetica Partindo do ponto de vista dos Game Designers osJD satildeo construiacutedos a partir da Mecacircnica (conjunto de regras) que sustenta a Dinacircmicado jogo (o sistema de jogo) A uniatildeo desses dois elementos proporcionam a Esteacutetica aojogador ou seja a experiecircncia que o Game Designer deseja proporcionar Por outro ladoa partir da perspectiva do jogador a Esteacutetica eacute a resposta emocional que os JD provocamno jogador tendo como base o seu comportamento perante a Dinacircmica do jogo criadapelos componente algoritmos e tecnologia utilizada na construccedilatildeo da Mecacircnica do jogo(HUNICKE LEBLANC ZUBEK 2004)

A Figura 216 ilustra o objetivo final do MDA Somente os componentes mecacircnica di-nacircmica e esteacutetica satildeo apresentados mas satildeo enxergados a partir do ponto de vista doscriadores e consumidores dos jogos No acrocircnimo MDA apresentado na Figura 216 aletra M representa Mecacircnica (Mechanics) a letra D representa Dinacircmica (Dynamics) ea letra A representa Esteacutetica (Aesthetics)

Figura 216 Principais elementos de design sugeridos pelo framework MDA (Mecacircnica Dinacircmicae Esteacutetica) representados pelas letras M D A respectivamente Fonte Adaptado de HunickeLeBlanc amp Zubek (2004)

45

Capiacutetulo Trecircs

Modelo de Desenvolvimento de Jogos Digitais

Aqui analisaremos o Modelo que relaciona os principais conceitos envolvidos do processode Desevolvimento de Jogos Digitais e o protocolo para descriccedilatildeo dos Jogos Digitais

31 O Modelo de Desenvolvimento de Jogos Digitais

311 O objetivo

O principal objetivo do Modelo de Desenvolvimento de Jogos Digitais (MDJD) eacute construirum link que relacione os desenvolvedores os jogadores e os diversos conceitos que estatildeoenvolvidos no processo de desenvolvimento dos JD Para isso utilizamos a categorizaccedilatildeode Werbach amp Hunter (2012) e definimos as trecircs categorias baacutesicas para construccedilatildeo deatividades gamificadas O conjunto de componentes do MDJD foram criados a partir asestrutura e organizaccedilatildeo de Grimm et al (2006) a relaccedilatildeo que existe entre as categoriasdo MDJD foram adaptadas de Werbach amp Hunter (2012) e a visatildeo do produto final dodesenvolvimento a partir da perspectiva dos desenvolvedores e dos jogadores foi adaptadode Hunicke LeBlanc amp Zubek (2004)

O MDJD ilustrado na Figura 31 nasceu do amadurecimento do modelo apresentadoem Diniz Monteiro amp Carneiro (2016) que embora tenha o objetivo de orientar a con-cepccedilatildeo de Objetos de Aprendizagem Gamificados e o foco voltado para construccedilatildeo decomponentes pedagoacutegicos nos ajudou a perceber que o principal objetivo do MDJD de-veria ser estruturante Deveriacuteamos construir um modelo que se apresentasse como umarcabouccedilo um conjunto de lacunas com definiccedilotildees bem construiacutedas para que os desenvol-vedores pudessem definir o seu conteuacutedo Dessa forma o nosso modelo estaria definindoo que deve ser feito e natildeo como deve ser feito Essa abordagem evidencia que natildeo existeuma metodologia oacutetima para o desenvolvimento de JD (SCHELL 2014 FULLERTON2014 SALEN ZIMMERMAN 2012) cada projeto deve utilizar uma metodologia queseja compatiacutevel com o tipo de jogo e as necessidade do grupo de pessoas envolvidas noprocesso de desenvolvimento

46

Capiacutetulo Trecircs 31 O Modelo de Desenvolvimento de Jogos Digitais

312 As categorias e a relaccedilatildeo entre os seus itens

Conforme descrito por Werbach amp Hunter (2012) as trecircs categorias baacutesicas (DinacircmicaMecacircnica e Componentes) agrupam respectivamente estrateacutegias regras e elementos quesatildeo responsaacuteveis pelo Sistema de Jogo e pela resposta emocional dos jogadores Elas satildeoresponsaacuteveis pela construccedilatildeo de um Sistema Fechado e Formal no qual um conjunto deregras iraacute orientar as accedilotildees dos jogadores dentro de um ambiente que representa de formasubjetiva um subconjunto do mundo real (CRAWFORD 1984)

No MDJD a categoria Dinacircmica de Jogo eacute composta por duas subcategorias a primeiraPropoacutesito eacute bem conceitual e tem o objetivo de definir as experiecircncias que os jogadoresiratildeo vivenciar Todo esforccedilo e dedicaccedilatildeo que o jogador investe no JD estaacute diretamenterelacionado ao objetivo principal o propoacutesito maior que ele tem que atingir ao final dojogo As Estrateacutegias de Gamificaccedilatildeo satildeo os mecanismos que o game designer vai utilizarpara impelir o jogador de sempre buscar atingir o objetivo final do jogo

Nos jogos da trilogia Mass Effect o jogador precisa derrotar um exeacutercito de maacutequinasinteligentes chamadas Reapers para evitar a extinccedilatildeo de todas as espeacutecies inteligentes danossa galaacutexia Para isso o jogador utiliza naves espaciais veiacuteculos de guerra faz alianccedilascom povos de diferentes espeacutecies visita planetas de diferentes sistemas solares para obterrecursos e solucionar problemas ganha medalhas pontos tem acesso a novas partes dojogo que antes estavam inacessiacuteveis tudo isso sempre visando aumentar as suas chancesde derrotar os Reapers No exemplo citado acima podemos notar a sutileza da relaccedilatildeoentre os dois elementos da categoria O viacutenculo eacute tatildeo sutil que fora do aspecto teoacutericoou seja durante a execuccedilatildeo do jogo eacute difiacutecil perceber a fronteira entre esses dois elementos

A segunda categoria do MDJD Mecacircnica do Jogo reuacutene o conjunto de regras e restri-ccedilotildees que delimitam as accedilotildees dos jogadores dentro do ambiente de jogo Esses itens satildeode extrema importacircncia para concepccedilatildeo e desenvolvimento dos JD Eles satildeo responsaacuteveispelas relaccedilotildees entre os jogadores estimulam a cooperaccedilatildeo e trabalho em equipe e satildeoresponsaacuteveis pelo aprimoramento dos jogadores Essas caracteriacutesticas e a influecircncia queelas tecircm dentro dos JD e entre os jogadores satildeo observadas nos jogos da franquia DestinyNesses jogos existem uma seacuterie de equipamentos (armas armaduras e veiacuteculos) e fasesque o jogador soacute tem acesso depois que ele atingir um certo grau de habilidade ou efetuarum conjunto de tarefa Aleacutem disso existem fases que necessariamente soacute podem serconcluiacutedas quando dois ou mais jogadores trabalham juntos para derrotar um inimigo ouresolver um problema que precisa de habilidades que natildeo satildeo encontradas em somente umpersonagem

47


A terceira e uacuteltima categoria do MDJD Componentes dos Jogos agrupa os itens baacutesi-cos da mecacircnica dos JD Eles satildeo como uma interface direta com o jogador Ela possuitrecircs subcategorias que classifica os seus itens a partir da natureza de cada um deles Asubcategoria Fatores Graacuteficos eacute composta por itens que os jogadores tecircm contato diretodurante o jogo Satildeo os modelos 2D ou 3D que compotildeem o conjunto de objetos artiacutesticosdo Jogo como itens dos jogadores veiacuteculos paisagens filmes NPCs medalhas tabelasde pontuaccedilatildeo entre outros

A Narrativa eacute a histoacuteria que ambientaliza o jogador dentro do jogo Ela constroacutei umalinha guia dentro do ambiente de jogo Ela estaacute diretamente relacionada com a categoriaDinacircmica do Jogo Por fim temos a subcategoria Fatores teacutecnicos Nesta categoria estaacute ogrupo de teacutecnicas e tecnologias utilizado para desenvolver os JD e possibilitar a interaccedilatildeodos jogadores com o ambiente e com outros jogadores Para melhor entendimento sobreessa subcategoria iremos citar o JD Battlefield 4 Neste jogo de tiro em primeira pessoa osjogadores estatildeo em um campo de batalha duelando entre times Uma das funcionalidadesdesse JD possibilita utilizar um dispositivo moacutevel smartphone ou tablet para acessar ummoacutedulo do jogo chamado ldquoModo Commanderrdquo Com essa funcionalidade eacute posiacutevel entrarno jogo como um teacutecnico e auxiliar a movimentaccedilatildeo do seu time dentro do campo debatalha

Todas as categorias e subcategorias acima descritas representam e agrupam conceitos im-portantes para o desenvolvimento de JD Poreacutem isoladamente elas trazem pouco sentidopraacutetico para desenvolvedores com pouca experiecircncia na construccedilatildeo de JD Para resol-ver esse problema decidimos aplicar o mesmo princiacutepio utilizado por Werbach amp Hunter(2012) e criamos relacionamentos entre os itens das diferentes categoriassubcategoriasPara isso os itens funcionais da categoria Componentes dos Jogos devem estar relaci-onados a pelo menos um dos itens da categoria Mecacircnica dos Jogos Isso garante quetodos os elementos baacutesicos com os quais o jogador precisa interagir durante o jogo tenhafuncionalidade Essa regra natildeo se aplica a todos Componentes dos Jogos apenas aoscomponentes funcionais

Da mesma forma todos os itens da categoria Mecacircnica dos Jogos devem estar relacionadoscom pelo menos um dos itens da categoria Dinacircmica dos Jogos Neste caso natildeo existeexceccedilatildeo Todos os elementos relacionados agraves questotildees Mecacircnicas do Jogo devem estarrelacionados com o propoacutesito ou com uma das estrateacutegias de gamificaccedilatildeo do JD

48


Figura 31 Na imagem A observamos a perspectiva dos Desenvolvedores Em B observa-mos a perspectiva dos Jogadores Fonte elaborado pelo autor

313 As perspectivas dos desenvolvedores e jogadores

Um ponto muito importante e que precisa ser considerado durante o processo de desen-volvimento de JD satildeo as diferentes percepccedilotildees dos agente envolvidos na construccedilatildeo dosJD Hunicke LeBlanc amp Zubek (2004) apresentam uma sugestatildeo que convida estudiosose pesquisadores da aacuterea a decompor os JD e com isso entendecirc-los a partir da perspectivados desenvolvedores e dos jogadores Fullerton (2014) apresenta uma abordagem que elachama de ldquoa Playcentric approachrdquo na qual os jogadores satildeo colocados dentro do processode desenvolvimento dos JD como uma figura ativa com a funccedilatildeo de validar as experiecircnciasque os JD proporcionam a eles

Seguindo a mesma linha de raciociacutenio de Hunicke LeBlanc amp Zubek (2004) e Fullerton(2014) apresentamos no MDJD duas figuras ambas com a atenccedilatildeo voltada para o jogomas com preocupaccedilotildees e anseios diferentes Os desenvolvedores tecircm como principal ob-jetivo construir o conjunto de experiecircncias que os jogadores iratildeo vivenciar partindo daDinacircmica do Jogo seguindo as regras e restriccedilotildees da Mecacircnica e utilizando os Compo-

49


nentes dos Jogos Fullerton (2014) apresenta trecircs exemplos que ilustram o ponto centralda preocupaccedilatildeo da equipe de desenvolvimento Eles satildeo

os jogadores teratildeo de cooperar para vencer mas o jogo seraacuteestruturado de forma que eles nunca possam confiar uns nosoutros [ ] os jogadores vatildeo sentir uma sensaccedilatildeo de felicidade edescontraccedilatildeo ao inveacutes de competitividade [ ] os jogadores teratildeoa liberdade de escolher quais objetivos eles querem perseguir (FULLERTON 2014)

Jaacute os jogadores os consumidores dos JD enxergam os jogos a partir de outras lentesEles tecircm contato com o jogo atraveacutes dos Componentes e a partir deles vivenciam asexperiecircncias do ambiente projetadas na Dinacircmica dos Jogos e regidas pela Mecacircnica Po-demos encontrar um bom exemplo da interaccedilatildeo dos jogadores com o ambiente de jogo emMcGonigal (2011) quando ela descreve o conceito de produtividade prazerosa

produtividade prazerosa eacute a sensaccedilatildeo de estar profunda-mente imerso no trabalho que produz resultados imediatos e oacuteb-vios Quanto mais claros os resultados e quanto mais raacutepidoos alcanccedilarmos mais felizes e produtivos nos sentiremos E ne-nhum jogo nos daacute uma sensaccedilatildeo melhor de conseguir visualizaro trabalho feito do que World of Warcraft [] sua missatildeo prin-cipal em World of Warcraft eacute auto-aperfeiccediloamento - um tipo detrabalho que quase todos noacutes achamos naturalmente atraenteVocecirc tem um avatar e seu objetivo eacute fazer com que ele seja me-lhor mais forte e mais rico de todas as maneiras possiacuteveis maisexperiecircncia mais habilidades armadura mais forte mais habili-dades mais talento e uma maior reputaccedilatildeo (MCGONIGAL2011)

314 O protocolo para descriccedilatildeo dos Jogos Digitais

Motivados pelo desejo de apresentar propostas que interfiram positivamente no processode desenvolvimento de JD sugerimos um meacutetodo criado a partir de uma das possiacuteveisleituras e interpretaccedilotildees do MDJD Trata-se de um protocolo ilustrado na Figura 32que possibilita a construccedilatildeo de um documento de designer que descreve todas as ideiasregras componentes e modelos matemaacuteticos que precisam ser implementados durante o

50


desenvolvimento de um JD Ele foi idealizado a partir das duas versotildees do protocolo ODD(GRIMM et al 2006 GRIMM et al 2010)

Ele consiste de oito elementos que estatildeo agrupados em trecircs blocos (Dinacircmica Mecacircnicae Componentes) e seguem as mesmas especificaccedilotildees das categorias (Dinacircmica de JogoMecacircnica do Jogo e Componentes do Jogos) apresentadas na Seccedilatildeo 311 Poreacutem o blocoMecacircnica possui trecircs elementos (Interatividade Regras e Modelos Matemaacuteticos) pararetratar todos os aspectos envolvidos na interaccedilatildeo entre o jogador e o ambiente de jogoA ideia baacutesica deste protocolo eacute que qualquer pessoa possa rapidamente ter noccedilatildeo dotrabalho que deve ser feito lendo as especificaccedilotildees de cada elemento do protocolo e se-guindo o fluxo de conexotildees sugerido pelo MDJD Para alcanccedilar um melhor entendimentoa respeito das seccedilotildees do protocolo apresentamos cada uma delas na Tabela 31 e dispo-nibilizamos no Apecircndice A um exemplo de aplicaccedilatildeo do Protocolo para descriccedilatildeo de JDcaracterizando um dos jogos mais populares do mundo (TETRIS 1996)

Figura 32 Protocolo para descriccedilatildeo de Jogos Digitais Fonte elaborado pelo autor

A utilizaccedilatildeo deste protocolo em conjunto com duas praacuteticas colaborativas que iremosapresentar no proacuteximo capiacutetulo viabiliza a reduccedilatildeo de problemas de comunicaccedilatildeo e pla-nejamento A ideia central eacute que esse protocolo seja utilizado como uma ferramenta peloProduct Owner e sirva como um guia para definir a prioridade dos requisitos que iratildeocompor o Product Backlog do JD

Outro ponto positivo que esse protocolo proporciona apresenta-se quando deixamos deenxergar os JD como artefatos com foco voltado para o entretenimento e passamos aobservaacute-los como objetos de estudos cientiacuteficos Os serious games (ABT 1987 MI-

51


CHAEL CHEN 2005) jogos cujo propoacutesito natildeo estaacute exclusivamente voltado para oentretenimento satildeo utilizados com finalizadades terapeuticas educacionais e sociocultu-rais desde o fim da deacutecada de 1980 (WILKINSON 2016) Partindo desse ponto de vistaum dos grande problemas enfrentados pelos estudiosos da aacuterea estaacute na anaacutelise e descriccedilatildeodos JD

Mesmo contando com a contribuiccedilatildeo de trabalhos com os de Hense amp Mandl (2012) ePetry et al (2013) a anaacutelise dos JD ainda eacute realizada de forma verbal fato que dificulta areproduccedilatildeo das experiecircncias construiacutedas no JD Devido a isso a utilizaccedilatildeo de um protocolopadratildeo para descriccedilatildeo de JD contribuiraacute para aumentar a credibilidade cientiacutefica dos JDdevido agrave possibilidade de reproduccedilatildeo das experimentaccedilotildees vivenciadas pelos jogadores

52


Bloco Seccedilatildeo Definiccedilatildeo

Dinacircmica 1- Propoacutesito Essa seccedilatildeo apresenta o obje-tivo principal do JD e as tare-fas que seratildeo realizadas paraalcanccedilar o objetivo principal

2- Estrateacutegias Gamificadas Aqui apresentamos as estrateacute-gias e mecanismos utilizadospara manter o jogador vincu-lado agrave histoacuteria que ambienta-liza ao JD

Mecacircnica3- Interatividade Apresenta de forma sucinta

as tecnologias utilizadas parapossibilitar a interaccedilatildeo dos jo-gadores com o ambiente de jo-gos e com outros jogadores

4- Regras Esta seccedilatildeo armazena todas asregras e restriccedilotildees que seratildeoimplementadas no JD

5- Modelos matemaacuteticos Esta seccedilatildeo apresenta a descri-ccedilatildeo detalhada de todos os mo-delos e relaccedilotildees matemaacuteticaque seratildeo implementadas nosJD

Componentes6- Narrativa Aqui apresentamos a histoacuteria

que orienta o jogador do iniacute-cio ao fim dos JD Ela tambeacutemapresenta as histoacuterias pontu-ais que o jogador vivenciapara executar tarefas dentrodo jogo

7- Fatores graacuteficos Esta seccedilatildeo apresenta a descri-ccedilatildeo detalhada de todos os ob-jetos modelos 2D ou 3D quepossuem funcionalidade den-tro dos JD

8- Fatores teacutecnicos Aqui apresentamos todas asteacutecnicas e tecnologias com ri-queza de detalhes utilizadaspara desenvolver os JD

Tabela 31 Blocos e seccedilotildees do protocolo para descriccedilatildeo de Jogos Digitais Fonte elaborado peloautor

53

Capiacutetulo Quatro

Sugestotildees para o Framework Scrum

Aqui seraacute apresentado o conjunto de sugestotildees que acreditamos que potencializaraacute a cola-boraccedilatildeo entre os membro da equipe de Desenvolvedores As sugestotildees estatildeo diretamenterelacionadas com a reuniatildeo de planejamento do sprint Sprint planning e a verificaccedilatildeodos itens produzidos durante o Sprint

41 Apresentaccedilatildeo

As sugestotildees que estatildeo descritas neste capiacutetulo foram construiacutedas com base em experi-ecircncias empiacutericas vivenciadas durante o desenvolvimento JD SimGE e LIPISpace e napesquisa bibliograacutefica efetivada neste projeto Inicialmente julgamos que os pontos quedeveriam ser aprimorados se originavam de situaccedilotildees especiacuteficas mas encontramos publi-caccedilotildees com observaccedilotildees e preocupaccedilotildees semelhantes agrave nossa fato que nos impulsionou acontinuar realizando esta pesquisa

A maior parte dos profissionais que estavam envolvidos nos projetos de desenvolvimentodos JD que foram analisados natildeo tinham experiecircncia com o Scrum (SCHWABER SUTHER-LAND 2013) As equipes eram formadas por pedagogos professores e programadoresTodos eles tinham estudado ou utilizado em algum momento de vida acadecircmica ou pro-fissional alguma metodologia baseada na metodologia castata (ROYCE 1970) Para elesdividir o projeto em etapas e executaacute-las uma apoacutes a outra era natural e indispensaacutevelDevido a isso natildeo foi possiacutevel aplicar todos os artefatos e eventos do Scrum Somentealguns foram aplicados com adapataccedilotildees e restriccedilotildees

Esse ambiente de trabalho restringia o fluxo de atividades ideal para o desenvolvimentode JD e gerou dois grandes problemas os Desenvolvedores natildeo eram ouvidos durante aconstruccedilatildeo ou reconstruccedilatildeo do planejamento e os trabalhos (de programaccedilatildeo e artiacutestico)eram realizados separadamente A interaccedilatildeo entre os Desenvolvedores durante a produccedilatildeoe verificaccedilatildeo dos artefatos construiacutedos era pequena

Esses mesmos problemas foram encontrados em publicaccedilotildees acadecircmicas Preocupadoscom a forma que os JD satildeo desenvolvidos Hunicke LeBlanc amp Zubek (2004) Godoy

54

Capiacutetulo Quatro 42 O Poker Planning com jogadas colaborativas

amp Barbosa (2010) Gregory (2010) falam da importacircncia de se trabalhar com processosou metodologia que privilegiam a possibilidade de executar diversas tentativas ou in-teraccedilotildees ateacute encontrar as caracteriacutestias que fazem os JD prazerosos para os jogadores(find the fun ou fun of the game) Aleacutem disso Petrillo et al (2008) Godoy amp Barbosa(2010) Keith (2010) falam da importacircncia do planejamento e a necessidade de trabalharcom a incerteza Essas praacuteticas exigem grande interaccedilatildeo entre os membros da equipe dedesenvolvimento e participaccedilatildeo ativa dos Desenvolvedores em reuniotildees de planejamentofato que propicia a construccedilatildeo de um ambiente de trabalho no qual a aprendizagem e acooperaccedilatildeo ocorrem de forma contiacutenua

Encontramos tambeacutem autores que relatam falhas no desenvolvimento de JD devido agraveperda do caraacuteter multidisciplinar das equipes de desenvolvimento Esse problema acon-tece quando as praacuteticas laborais de cada especialidade satildeo realizadas isoladamente quandoo profissional se fechadentro da sua expertise para relizar o seu trabalho e esquece o ca-raacuteter multidisciplinar (diferentes aacutereas do conhecimento trabalhando juntas para resolverum problema) que existe intriacutenseco ao processo de desenvolvimento de JD (HUNICKELEBLANC ZUBEK 2004 GODOY BARBOSA 2010)

Essas constataccedilotildees cientiacuteficas e o contato direto com equipes de desenvolvimento deramorigem a duas sugestotildees A primeira que tem o objetivo de aumentar o niacutevel de deta-lhamento e a participaccedilatildeo de todos os membros da equipe de desenvolvimento durante aestimativa do trabalho trata-se de uma modificaccedilatildeo na praacutetica gamificada chamada PokerPlanning (GRENNING 2002) A segunda diz respeito a uma das etapas de trabalho dosprint e foi adaptada com base nas metodologia de desenvolvimento XP (BECK 2009) edaraacute origem a um item de verificaccedilatildeo do documento com as Definiccedilotildees de Pronto DOD

Acreditamos que essas duas sugestotildees diminuiratildeo os erros de estimativas do trabalhoque deve ser desenvolvido fato que tem impacto direto no planejamento e minimizaratildeoa possibilidade de individualizaccedilatildeo do trabalho durante a construccedilatildeo dos JD fato quecontribuiraacute para produccedilatildeo de JD que expressam os aspectos multidisciplinares criados ediscutidos pela equipe de desenvolvimento

42 O Poker Planning com jogadas colaborativas

A praacutetica apresentada por Grenning (2002) chamada de Poker Planning tem como princi-pal objetivo definir uma estimativa para cada um dos requisitos apresentados pelo clienteNatildeo existe o comprometimento com a precisatildeo o propoacutesito maior eacute construir o escopo do

55


projeto a partir de uma visatildeo geral dos requisitos que seratildeo implementados

De acordo com Cohn (2005) o Poker Planning (GRENNING 2002) eacute uma praacutetica bemaplicada para o definiccedilatildeo do escopo de requisitos de qualquer tipo de Sistema Eacute muitodifiacutecil e pouco provaacutevel que no iniacutecio de um projeto seja possiacutevel determinar todas asnuances dos requisitos que seratildeo implementados As metodologias Aacutegeis natildeo pregam issoe aleacutem disso grande parte os requisitos apresentados pelo cliente natildeo seratildeo implementa-dos (SUTHERLAND 2016)

Poreacutem quando estamos falando sobre planejamento de JD existem aspectos multidisci-plinares que natildeo podem ser ignorados quando estamos estimando os requisitos de um JDDevido a isso apresentamos uma dinacircmica cuja anaacutelise da estimativa leva em considera-ccedilatildeo as jogadas de todos os jogadores para formar um resultado final similar a um jogode Poker As cartas ou jogadas que representam a estimativa de cada jogador seratildeocombinadas durante a discussatildeo entre os membros da equipe para construir a estimativaSegue abaixo o passo a passo de uma jogada de Poker Planning segundo a nossa sugestatildeo

1 Cada membro da equipe utiliza um conjunto de cartas

2 O Cliente ou Product Owner lecirc o requisito e o discute com a equipe de desen-volvimento

3 Cada membro escolhe as cartas com as suas estimativas Duas cartas detipo (programaccedilatildeo ou artes) e duas cartas de tamanho (nuacutemeros)

4 Todos juntos mostram as suas cartas

5 No showdown as cartas satildeo combinadas para definir conjuntamente a melhorestimativa para a user story apresentada

Ao analisar o passo a passo descrito acima percebemos que somente os itens destacadosem vermelho trecircs e cinco satildeo diferentes da proposta original No ponto trecircs o desevol-vedor escolhe quatro cartas para relizar a estimativa No ponto cinco os desenvolvedoresutilizam o conjunto de jogadas para colaborativamente compor a melhor estimativacombinando as cartas exibidas pelo desenvolvedores de forma similar ao showdown dojogo de poker (HARRINGTON 2005)

Neste ponto temos que ressaltar as duas mudanccedilas A primeira diz respeito ao conjuntode cartas do baralho Na proposta original de Grenning (2002) as cartas tinham osvalores 1 2 3 5 7 10 e infinito Publicaccedilotildees atuais utilizam letras e ateacute animais nosbaralhos (COHN 2005) Nesta proposta utilizaremos as cartas 0 12 1 2 3 5 8 13

56


20 40 100 infinito e ilustradas na figura 41 apresentadas em Cohn (2005) e maisduas cartas uma para representar o trabalho de programaccedilatildeo e outra para o trabalhoartiacutestico ilustradas na figura 42

Figura 41 Cartas do baralho de Poker Planning Fonte (COHN 2005)

Para facilitar o entendimento e dar significado a cada carta a Tabela 41 apresenta ainterpretaccedilatildeo de cada uma delas Os valores apresentados na coluna cartasda tabela 41representam a quantidade de horas que a terefa precisa para ser concluiacuteda (GRENNING2002 DUARTE 2016) Todavia devemos ressaltar que esses nuacutemeros servem apenaspara dar uma ideia do tempo necessaacuterio para execuccedilatildeo da terafa natildeo existe um modeloou foacutermula que transforme os valores das estimativar do Poker Planning em horas natildeo temprecisatildeo nessa praacutetica e as metodologias Aacutegeis natildeo pregam isso (SUTHERLAND 2016)Geralmente o Scrum Master leva dois ou trecircs sprints para encontrar a velocidades que aequipe consegue trabalhar e dessa forma definir quantos pontos e equipe desenvolve emum sprint (KEITH 2010)

Cartas Interpretaccedilatildeo0 A tarefa jaacute estaacute completa12 A tarefa eacute muito pequena

1 2 3 A tarefa eacute pequena5 8 13 A tarefa eacute de tamanho meacutedio20 40 A tarefa eacute grande100 A tarefa eacute muito grandeinfin A tarefa eacute enorme Natildeo sei o tamanho da tarefa

Tabela 41 As cartas do baralho de Poker Planning e seus signifados Fonte Adaptado de Cohn(2005)

As duas cartas que a nossa sugestatildeo recomenda adicionar na dinacircmica do Poker Planningtrabalho de programaccedilatildeo e trabalho artiacutestico ilustradas na Figura 42 seratildeo utilizadaspara que cada desenvolvedor possa estimar o esforccedilo de programaccedilatildeo e artiacutestico neces-saacuterio para realizar a tarefa descrita no requisito do cliente ou Product Owner em umamesma jogada

57


A segunda mudanccedila que a nossa dinacircmica sugere eacute a utilizaccedilatildeo de todas as jogadas asestimativas de todos os Desenvolvedores para compor a jogada vencedora e a estimativacom mais detalhes Todos os Desenvolvedores poderatildeo combinar as cartas de diferentesjogadas para construir as estimativas que mais se aproximem da user story descrita pelocliente ou Product Owner Vale ressaltar que natildeo estamos falando sobre precisatildeo Nesteponto eacute importante reafirmar que o objetivo principal dessa dimacircnica eacute aumentar o niacutevelde detalhamento e a participaccedilatildeo de todos os membros da equipe de desenvolvimento

Figura 42 A carta da esquerda representa o trabalho de programaccedilatildeo A carta da direitarepresenta o trabalho artiacutestico

Fonte elaborado pelo autor

A diferenccedila entre a nossa sugestatildeo e a proposta orginal estaacute na forma que o requesito eacutemensurado Grenning (2002) afirma que o tamanho do requisito eacute definido apoacutes sucessi-vas interaccedilotildees entre os desenvolvedores que apresentam argumentos para justificar a suaestimativa As interaccedilotildees acabam quando todos chegam a um consenso e apresentam amesma estimativa Na nossa dinacircmica o esforccedilo do trabalho de programaccedilatildeo e artiacutesticoeacute mensurado simultaneamente cada desenvolvedor apresenta argumentos para aumentaro niacutevel de detalhamento da atividade Isso proporciona trecircs vantagens

bull O foco da dinacircmica natildeo estaacute na vitoacuteriade um desenvolvedor que convence seuscolegas e encaminha o consenso A colaboraccedilatildeo eacute o centro da atividade

bull Os aspectos multidisciplinares que surgem na reuniatildeo de planejamento do SprintSprint planning ficam evidenciados na estimativa

bull Ao final da dinacircmica a estimativa total tambeacutem apresentaraacute as estimativas dasatividades (estimativas parciais) que seratildeo realizadas para o desenvolvimento dorequisito definido pelo cliente ou Product Owner

Para exemplificar vamos criar o seguinte cenaacuterio O Product Owner lecirc um dos requisitosdo jogo para uma equipe de trecircs desenvolvedores Os desenvolvedores tiram suas duacutevidasescolhem as suas cartas e apresentam as jogadas ilustradas na Figura 43 A primeira

58


coisa que podemos notar eacute que o perfil do desenvolvedor teraacute influecircncia direta na suaestimativa Neste cenaacuterio hipoteacutetico vamos assumir que a jogada a(cartas vermelhas)apresentada na figura 43 eacute a estimativa de um programador e a jogada c(cartas la-ranjas) a estimativa de um desenhista Ambos natildeo apresentam estimativas para o esforccedilonecessaacuterio para realizaccedilatildeo do trabalho fora da sua aacuterea de experiecircncia Poreacutem a jogadab(cartas verdes) ilustra a estimativa de um profissonal que possui experiecircncia nas duasaacutereas (programaccedilatildeo e desenho) As trecircs jogadas expressam a periacutecia de diferentes profis-sionais eacute justamente por isso que as trecircs precisam ser analisadas para definiccedilatildeo de umaestimativa que possua mais detalhes e apresente o caraacuteter multidisciplinar dessa atividade

Figura 43 Exemplo de estimativa de uma equipe com trecircs desenvolvedores Fonte elaboradopelo autor

Ainda utilizando o cenaacuterio descrito acima vamos fazer algumas combinaccedilotildees com as joga-das ilustradas na Figura 43 para exemplificar o funcionamento da dinacircmica proposta pelanossa sugestatildeo e exibir alguns dos resultados possiacuteveis Os resultados ae bretratadosna Figura 44 apresentam uma curiosidade Os desenvolvedores concordam quanto agrave esti-mativa do trabalho de programaccedilatildeo (tamanho 8) mas utilizam a mesma praacutetica definidapor Grenning (2002) para definiccedilatildeo do trabalho artiacutestico Na jogada a eles definem queo esforccedilo necessaacuterio para o desenvolvimento do trabalho artistico eacute 3 e na jogada beleschagaram a um consenso que o esforccedilo necessaacuterio eacute 5 Eacute importante ressaltar esse tipode resultado porque ele demonstra que a dinacircmica que noacutes estamos sugerindo tambeacutempermite que um desenvolvedor convenccedila os seus colegas de trabalho que uma atividadefoi superestimada ou subestimada

Os resultados ce dilustrados na Figura 44 apresentam resultados que demonstramas vantagens da nossa sugestatildeo No resultado c os desenvolvedores concordaram queo tamanho do trabalho de programaccedilatildeo eacute 8 poreacutem as estimativas do trabalho artiacutesticoilustradas na Figura 43 apresentaram contribuiccedilotildees distintas (ressaltando que as joga-das foram feitas por desenvolvedores com perfis diferentes) e devido a isso as duas foramagregadas agrave estimativa do trabalho artiacutestico O resultado cda Figura 44 define o ta-manho 8 para o trabalho artiacutestico 3 de um aspecto apresentado pelo desenvolvedor be

59

Capiacutetulo Quatro 43 Verificaccedilatildeo multidisciplinar

5 de um ponto levantado pelo desenvolvedor c ambos ilustrados no escopo da figura 43

No resultado d da Figura 44 os desenvolvedores apresentam contribuiccedilotildees distintaspara os dois tipos de trabalho Devido a isso as contribuiccedilotildees satildeo somadas agrave estimativaComo resultado final temos o tamanho 10 (8 + 2) para o trabalho de programaccedilatildeo e 8(5 + 3) para o trabalho artiacutestico Notem que as estimativas finais ilustradas nas jogadasce dda Figura 44 (estimativa total) tambeacutem apresentam as estimativas das ativida-des (estimativas parciais) necessaacuterias para desenvolvimento da user story

Figura 44 Exemplo de estimativa apoacutes o Showdown Fonte elaborado pelo autor

43 Verificaccedilatildeo multidisciplinar

O conjuto de valores e princiacutepios apresentados por Beck (2009) tem o objetivo de criar umestilo de programaccedilatildeo que prioriza as interaccedilotildees e os constantes feedbacks entre os mem-bros da equipe e o cliente final Entre as praacuteticas que concretizam os valores e princiacutepiosda XP destacaremos duas que seratildeo a base da nossa segunda sugestatildeo o DesenvolvimentoGuiado por Teste TDD e a Programaccedilatildeo em Pares Pair Programming

Todo o ciclo de desenvolvimento do XP eacute voltado para testes Conforme ilustrado naFigura 45 nesta metodologia vocecirc primeiro cria e executa os teste que iratildeo validar afuncionalidade depois produz as linhas de coacutedigo para construir a funcionalidade e porfim refatora o seu coacutedigo para aperfeiccediloaacute-lo Essa abordagem muda por completo a formaque o software eacute desenvolvido por duas razotildees os teste passam a ser o iniacutecio do trabalhodo desenvolvedor Antes de comeccedilar a codificar o programador eacute obrigado a pensar nocomportamento que o software pode assumir Aleacutem disso depois que os testes estatildeo cons-truiacutedos eles serviratildeo como um guia de desenvolvimento Eles induzem os desenvolvedores

60


a codificar evitando os erros que os testes provocam (PAULK 2001 BECK 2009)

Figura 45 Ciclo de Desenvolvimento guiado por testes TDD Fonte Paulk (2001)

Outro ponto central e marcante da metodologia de desenvolvimento XP eacute a Programa-ccedilatildeo em Pares A XP busca manter a comunicaccedilatildeo fluida entre os membros da equipede desenvolvimento e a Programaccedilatildeo em pares eacute uma das praacuteticas que viabilizam a in-terlocuccedilatildeo constante entre eles A ideia baacutesica da Programaccedilatildeo em Pares ilustrada naFigura eacute que a codificaccedilatildeo eacute compartilhada entre duas pessoas que utilizam o mesmocomputador assumindo papeacuteis diferentes (piloto e copiloto) e se revezando entre essasduas responsabilidades O piloto trabalha diretamente no coacutedigo construindo a estruturaloacutegica da funcionalidade que estaacute sendo desenvolvida O copiloto supervisiona o trabalhodo piloto verificando as estruturas de dados padrotildees de projeto nomenclatura de variaacute-veis e objetos jaacute pensando na refatoraccedilatildeo que ambos faratildeo depois de executar todos ostestes (BECK 2009)

61


Figura 46 Exemplo de Programaccedilatildeo em pares Fonte (BECK 2009))

Embora as empresas de desenvelvimento de JD normalmente natildeo apliquem testes preacute-definidos antes da criaccedilatildeo dos JD (KASURINEN SMOLANDER 2014) acreditamos queseja possiacutevel a definiccedilatildeo de uma rotina de verificaccedilotildees que objetiva analisar o resultadofinal da integraccedilatildeo das criaccedilotildees da equipe de desenvolvimento no sprint (fase 1) e a opniatildeodos usuaacuterios finais (fase 2) sobre o produto criado Essa praacutetica tem o propoacutesito de averi-guar a aderecircncia entre a concepccedilatildeo artiacutestica a trilha sonora jogabilidade e programaccedilatildeodo JD e com isso evitar o fatiamento das ideias geralmente causadas pela individualizaccedilatildeodo trabalho (HUNICKE LEBLANC ZUBEK 2004 GODOY BARBOSA 2010) Paraisso construiacutemos um ciclo de verificaccedilotildees ilustrado na Figura 47 similar ao TDD quedeve ser executado por pelo menos dois membros da equipe de desenvolvimento comperfis diferentes (ex um programador e um desenhista) e um jogador (usuaacuterio final)

62


Figura 47 Ciclo de Verificaccedilotildees Multidisciplinar Fonte elaborado pelo autor

Eacute muito importante ressaltar que o modelo apresentado na Figura 47 natildeo se aplica atodos produtos criados em um sprint Ele deve ser empregado a protoacutetipos funcionaisAtividades que objetivam construccedilatildeo das estruturas funcionais como banco de dados con-figuraccedilotildees e ajustes de IDE ou frameworks natildeo devem adicionar esse item no documentode DOD

Para facilitar o entendimento do modelo ilustrado na Figura 47 vamos considerar queuma equipe de trecircs pessoas (dois desenvolvedores e um jogador) vai efetuar o Ciclo deVerificaccedilotildees Multidisciplinar Na primeira fase somente os desenvolvedores participamda verificaccedilatildeo A primeira atividade da Fase 1 eacute analisar o produto criado no SprintOs desenvolvedores que possuem perfis diferentes vatildeo verificar se o produto final criadono Sprint estaacute alinhado com as definiccedilotildees apresentadas na Sprint planning pelo ProductOwner a partir do ponto de vista da sua aacuterea de especialidade Neste momento os de-senvolvedores natildeo trocam ideias ou sugestotildees Eles vatildeo somente analisar se o produtogerado pela integraccedilatildeo dos trabalhos dos desenvolvedores possuem ou expressam as ca-racteriacutesticas e propriedades artiacutesticas ou teacutecnicas na sua expertise

Na segunda atividade da Fase 1 os desenvolvedores vatildeo apresentar as suas anaacutelises sobreo protoacutetipo Eacute nesta etapa que ocorre o alinhamento entre a concepccedilatildeo artiacutestica e teacutecnicado JD que estaacute em desenvolvimento Possiacuteveis inconsistecircncias na arte ou comportamento

63


de qualquer um dos artefatos do protoacutetipo satildeo apresentadas e discutidas entre os desen-volvedores As observaccedilotildees que explicitam a necessidade de modificaccedilotildees no protoacutetipodevem ser encaminhadas para a terceira etapa da Fase 1 (novos itens satildeo adicionados nalista de atividade a fazer) Se natildeo houver modificaccedilotildees a Fase 1 eacute encerrada e passamospara Fase 2 da verificaccedilatildeo

A terceira etapa da Fase 1 eacute o momento de ajustes As inconsistecircncias que foram obser-vadas na segunda etapa satildeo corrigidas pela equipe de desenvolvedores Depois de efetuartodas modificaccedilotildees necessaacuterias uma nova versatildeo do protoacutetipo eacute gerada e a Fase 1 do Ciclode Verificaccedilotildees Multidisciplinar se inicia novamente

Na primeira etapa da Fase 2 ilustrada da Figura 47 o protoacutetipo eacute apresentado a umjogador um potencial consumidor do JD que estaacute sendo produzido Durante esse primeiromomento o jogador vai avaliar o protoacutetipo e construir uma opiniatildeo sobre o produto criadopela equipe de Desenvolvimento sem a presenccedila dos desenvolvedores No proacuteximo passoa segunda etapa da Fase 2 os desenvolvedores e o jogador se reuniratildeo para trocar expe-riecircncias e construir o feedback do jogador Nesta reuniatildeo os desenvolvedores explicaratildeoos objetivos artiacutesticos e teacutecnicos que eles queriam alcanccedilar com o protoacutetipo apresentadoe ouviratildeo a opiniatildeo do jogador sobre o produto desenvolvido

Neste ponto precisamos ressaltar a necessidade de colocar o usuaacuterio final jogador emcontato direto com a equipe de Desenvolvimento com uma funccedilatildeo ativa participandodo processo de construccedilatildeo do JD Essa necessidade jaacute foi destacada por outros autores(SCHELL 2014 SALEN ZIMMERMAN 2012 KEITH 2010) e descrita por Fullerton(2014) ao apresentar uma abordagem completamente centrada no jogador A PlaycentricApproach Nesta pesquisa a necessidade de inserir a percepccedilatildeo do jogador foi descrita nomodelo MDJD ilustrado na Figura 31

Na terceira e uacuteltima etapa da Fase 2 Figura 47 os desenvolvedores analisam o feedbackdo jogador O resultado dessa avaliaccedilatildeo pode levaacute-los a caminhos diferentes Se o jogadoraprovar a criaccedilatildeo da equipe de Desenvolvimento a Verificaccedilatildeo Multidisciplinar eacute finalizadae o protoacutetipo estaraacute pronto para ser apresentado na Sprint Review Se o jogador fizerobservaccedilotildees que explicitem a necessidade de modificaccedilotildees no protoacutetipo os Desenvolvedorespodem fazer duas escolhas

1 Reiniciar a Fase 1 da Verificaccedilatildeo multidisciplinar assumindo a responsabilidade e orisco de entregar o protoacutetipo no Sprint atual

64

Capiacutetulo Quatro 44 Visualizando as sugestotildees no framework Scrum

2 Finalizar a Verificaccedilatildeo multidisciplinar e apresentar na Sprint Review o protoacutetipo enovas user stories que descrevam as observaccedilotildees feitas pelo jogador

Por fim chamamos a atenccedilatildeo para uma situaccedilatildeo interessante mesmo quando o jogadoraprova o protoacutetipo apresentado na Verificaccedilatildeo Multidisciplinar as observaccedilotildees feitas porele durante a etapa de construccedilatildeo do feedback do jogador na Fase 2 podem dar origema novas user stories que seratildeo apresentadas ao Product Owner na Sprint Review Essasobservaccedilotildees podem oportunizar novas caracteriacutesticas e propriedades que o Product Ownere os Stakeholders natildeo observaram durante a definiccedilatildeo dos requisitos do JD

44 Visualizando as sugestotildees no framework Scrum

Depois de apresentar os produtos desenvolvidos nesta pesquisa vamos demostrar comoeles poderiam ser aplicados no desenvolvimendos dos JD que foram construiacutedos durantea execuccedilatildeo dessa investigaccedilatildeo Lembramos que a produccedilatildeo dos quatro produtos apre-sentados nesta pesquisa natildeo estavam finalizados durante o desenvolvimento dos JD queconstruiacutemos Para apresentar a aplicaccedilatildeo das nossas sugestotildees vamos considerar algumascenas dos jogos LIPISpace e SimGE

O primeiro exemplo diz respeito ao Poker Planning Colaborativo Conforme apresentaa Figura 48 a nossa primeira sugestatildeo seria aplicada no evento Sprint Planning pelaequipe de desenvolvedores Ela estaacute na porta de entrada do ciclo de desenvolvimento etem impacto direto na definiccedilatildeo dos requisitos e funcionalidades que iratildeo fazer parte doSprint Essa mensuraccedilatildeo cooperativa proporciona mais fidedignidade ao planejamento eaumenta o engajamento da equipe de desenvolvedores aos prazos e compromissos assumi-dos durante o planejamento do Sprint

65


Figura 48 Aplicaccedilatildeo do Poker Planning Colaborativo Fonte elaborado pelo autor

As cenas ilustradas na Figura 49 apresentam duas funcionalidades do LIPISpace Naimagem A da Figura 49 observamos uma nave espacial dois geradores e entre essestrecircs objetos um aacutetomo Os geradores produzem campos magneacuteticos que influenciam adireccedilatildeo das cargas eleacutetricas que satildeo liberadas pelo aacutetomo quando ele eacute estimulado porfeixes de luz produzidos pela nave espacial Aleacutem desses objetos observamos tambeacutemuma seacuterie de controles que comandam a movimentaccedilatildeo da nave o sentido e a direccedilatildeo doscampos eleacutetricos e os trecircs tipos de cargas eleacutetricas (eleacutetrons proacutetons e necircutrons)

Na imagem B da Figura 49 observamos a representaccedilatildeo de um aacutetomo segundo o mo-delo atocircmico de Niels Bohr Aleacutem disso temos tambeacutem as informaccedilotildees e a distribuiccedilatildeoeletrocircnica do aacutetomo e o diagrama de Linus Pauling Na parte inferior da cena estatildeoos controles que possibilitam a adiccedilatildeo e remoccedilatildeo de eleacutetrons do aacutetomo que estaacute sendoapresentado na tela

66


Figura 49 Cenas do Jogo Digital LIPISpace Fonte elaborado pelo autor

A construccedilatildeo das duas cenas apresentados na Figura 49 foram definidas por duas userstories descritas na Figura 410 Lembramos que as cenas apresentadas tem o objetivode unir o caraacuteter luacutedico dos Objetos de Apredizagem aos elementos dos JD (DINIZMONTEIRO CARNEIRO 2016) Na Figura 49 A os dois geradores fazem parteda espaccediloaacuteave Eles seguem a mesma movimentaccedilatildeo da nave Na Figura 49 B uti-lizamos esferas para representar os eleacutetrons proacutetons e necircutrons Essa imagem natildeo estaacuterespeitando a proporccedilatildeo real de tamanho dessas partiacuteculas O resultado final ilustradona Figura 49 foi alcanccedilado depois de dois Sprints Todas as cenas foram testadas porprofessores que validaram os conceitos Fiacutesicos a usabilidade e jogabilidade do LIPISpace

Figura 410 User stories das cenas ilustradas na Figura 49 Fonte elaborado pelo autor

As duas user stories descritas na Figura 410 foram classificadas como grandes Utiliza-mos o conjunto de cartas sugeridos por Cohn (2005) descrito na Tabela 41 A Figura411 ilustra como poderiam ser as jogadas utilizadas para mensurar as user stories des-critas na Figura 410

67


Figura 411 A imagem A representa a jogada da user storie descrita na Figura 410 A e a imagemB representa a jogada da user storie descrita na Figura 410 B Fonte elaborado pelo

autor

Para construir o segundo exemplo iremos continuar utilizando as cenas ilustradas na Fi-gura 49 Conforme exposto anteriormente essas duas cenas foram construiacutedas em doisSprints No final do primeiro Sprint as duas cenas foram analisadas por dois professoresde Fiacutesica Durante a anaacutelise eles encontraram trecircs erros conceituais e problemas relacio-nados a usabilidades

Como ainda faltavam dois dias para terminar o primeiro Sprint decidimos corrigir ostrecircs erros conceituais dentro do proacuteprio Sprint e criamos uma nova user storie ilustradana Figura 412 para registrar as sugestotildees apresentadas pelos professores Foi a partirdessa experiecircncia que obtivemos as ideias necessaacuterias para construirmos a Verificcedilatildeo Mul-tidisciplinar conforme apresentado na seccedilatildeo 43 A Figura 413 ilustra o momento que aVerificcedilatildeo Multidisciplinar seria aplicada e a formaccedilatildeo da equipe de trabalho responsaacutevelpela anaacutelise das cenas criadas

Figura 412 Nova User storie criada para adicionar uma nova funcionalidade na cena AdaFigura 49 Fonte elaborado pelo autor

68


Figura 413 Aplicaccedilatildeo da Verificcedilatildeo Multidisciplinar Fonte elaborado pelo autor

Para apresentar o terceiro exemplo utilizaremos duas cenas do JD SimGE ilustradas naFigura 414 O SimGE tem como principal objetivo expor os estudantes aos desafios dodia a dia de um gestor escolar O jogador precisa utilizar os recursos disponiacuteveis paraequipar as diversas instalaccedilotildees de uma escola enquanto responda uma seacuteria de perguntasque estatildeo diretamente relacionadas com as leis praacuteticas e a rotina diaacuteria de um gestorescolar

Figura 414 Cenas do Jogo Digital SimGE Fonte elaborado pelo autor

A cena ilustrada na Figura 414 Aapresenta uma escola e os seus seis ambientes (secre-taria biblioteca sala de aula laboratoacuterio de informaacutetica cozinha e o paacutetio) Na partesuperior da cena temos as informaccedilotildees sobre os recursos que o jogador tem para equipara escola (recursos de capital e custeio) o valor atual da experiecircncia do jogador e o tempo

69


que o jogador tem para utilizar os recursos Ressaltamos que o tempo estaacute diretamenterelacionado com o iniacutecio e fim ano letivo as datas fiscais a que o gestor precisa obedecere a experiecircncia do jogador

A segunda cena apresentada na Figura 414 Bmostra um dos desafios que o jogadorprecisa resolver durante o jogo Em intervalos aleatoacuterios perguntas de muacuteltiplas escolhassatildeo apresentadas para o jogador Todas as vezes que ele acerta uma pergunta ele ganhamais recursos de capital e custeio ou mais tempo para utilizaacute-los As perguntas fazemparte do conteuacutedo didaacutetico das disciplinas do primeiro e segundo semestres do curso deGestatildeo Escolar do Programa Profuncionaacuterio

Para ilustrar a utilizaccedilatildeo do Protocolo para descriccedilatildeo de JD apresentamos na Figura 415uma parte da definiccedilatildeo da seccedilatildeo Modelos Matemaacuteticos do bloco Mecacircnica Nela exibimosas relaccedilotildees matemaacuteticas que existem entre os conceitos de Recursos de Custeio Recursosde Capital Experiecircncia Tempo e Tipo de Pergunta

Figura 415 Exemplo de utilizaccedilatildeo de uma das seccedilotildees do Protocolo para descriccedilatildeo de JogosDigitais Fonte elaborado pelo autor

Conforme ilustrado na Figura 416 o Protocolo para descriccedilatildeo de Jogos Digitais daacute origema um documento de designer que pode ser utilizado durante a reuniatildeo de Sprint Planningpode ser consultado durante a execuccedilatildeo do Sprint e ainda pode ser atualizado para fazerparte do produto que seraacute apresentado na reuniatildeo de Review do Sprint A utilizaccedilatildeo deum protocolo que padronize a descriccedilatildeo dos JD possibilitaraacute a empresas que possuemprocessos de desenvolvimento com pouca maturidade ou equipes que possuem membroscom pouca experiecircncia no desenvolvimento de JD um documento guia estruturado e quepossui um conjunto de seccedilotildees que satildeo conceitualmente relacionadas tendo como base oMDJD

70


Figura 416 Aplicaccedilatildeo do Protocolo para descriccedilatildeo de Jogos Digitais Fonte elaborado peloautor

71

Capiacutetulo Cinco

Conclusotildees e Consideraccedilotildees finais

Para finalizar o trabalho neste capiacutetulo apresentam-se as consideraccedilotildees sobre o modeloMDJD o protocolo para descriccedilatildeo de JD e as sugestotildees de modificaccedilatildeo no frameworkScrum Apresentam-se tambeacutem outras contribuiccedilotildees da tese e as perspectivas de novasinvestigaccedilotildees

51 Conclusotildees

Com base no modelo construiacutedo apresentamos um protocolo para descriccedilatildeo de JD Eapoacutes identificar problemas em pontos cruciais do processo de desenvolvimento de JD (pla-nejamento e desenvolvimento) definimos duas praacuteticas que viabilizam a construccedilatildeo de JDsem deixar de lado duas caracteriacutesticas que satildeo intriacutensecas ao processo de desenvolvimentode JD a incerteza e a aprendizagem constante

O Modelo de Desenvolvimento de Jogos Digitais ilustrado na Figura 31 aglutina e apre-senta um conjunto de conceitos que norteiam o desenvolvimento de JD Nele podemosnotar dois pontos importantes O primeiro diz respeito aos atores envolvidos no processoAs diferentes perspectivas dos Desenvolvedores e Jogadores satildeo apresentadas no modeloA partir delas podemos observar a importacircncia do planejamento do trabalho artiacutesticoe teacutecnico (programaccedilatildeo) no desevolvimento de JD O equiliacutebrio entre essas trecircs forccedilasviabiliza a construccedilatildeo de JD que atende agraves demandas e anseios dos jogadores Poreacutempara alcanccedilar esse estado de equiliacutebrio eacute preciso utilizar uma metodologia de desenvol-vimento que possibilite trabalhar com a incerteza dos constates ajustes e modificaccedilotildeesque possibilite a adaptaccedilatildeo das suas praacuteticas e que possua o foco sempre voltado para oaprimoramento do produto Essas caracteriacutesticas e necessidades justificam a escolha doframework Scrum como modelo de gestatildeo dessa pesquisa

O segundo ponto positivo que o MDJD proporciona estaacute relacionado com o caraacuteter praacute-tico que ele oportuniza durante tomadas de decisatildeo em atividades de planejamento e naconcepccedilatildeo dos JD O relacionamento que existe entre os elementos das trecircs categorias doMDJD orienta os Game Designers a definir uma estrateacutegia de gamificaccedilatildeo e a relaci-ona com um conjunto de regras e componentes dos JD Esse agrupamento iraacute compor oSistema Fechado e Formal que iraacute gerar as respostas emocionais que o Game Designers

72

Capiacutetulo Cinco 51 Conclusotildees

deseja proporcionar ao jogador Para agentes cujas funccedilotildees estatildeo mais voltadas para oplanejamento como Product Ownerrsquos e Scrum Masterrsquos o relacionamento entre os ele-mentos das trecircs categorias pode ajudar a definir a prioridade dos requesitos que iratildeo entrarno Sprint e a ordem das atividades executadas

O protocolo para descriccedilatildeo de JD eacute o segundo produto apresentado nesta tese Ele foicriado a partir de uma leitura do MDJD e tem como principal objetivo a descriccedilatildeo formaldos JD Embora diversos autores utilizem e defendam os JD como objetos de ensino eaprendiagem e realizem pesquisas para aperfeiccediloar e potencializar a aplicaccedilatildeo dos JD naEducaccedilatildeo natildeo encontramos publicaccedilotildees que apresentem propostas para descriccedilatildeo formalde JD Devido isso os JD ainda satildeo descritos de forma verbal fato que dificulta a repro-duccedilatildeo das experiecircncias proporcionadas pelos JD devido agrave ambiguidade e leitura poucoacessiacutevel Um protocolo que padronize a descriccedilatildeo de JD resolve esse problema e aumentaa credibilidade cientiacutefica desse artefato

A grande vantagem que um protocolo padratildeo para descriccedilatildeo de JD nos traz estaacute na es-trutura que ele oferece aos escritores e leitores Ela facilitaraacute a absorccedilatildeo de informaccedilatildeograccedilas ao significado de cada camada da sua estrutura Devido a isso acreditamos que umprotocolo que apresente as explicaccedilotildees verbais separadas das especificaccedilotildees matemaacuteticasem uma estrutura baacutesica e comum a todos os tipos de JD vai ajudar a reproduccedilatildeo dosSistemas de jogo e das respostas emocionais planajedas pelos Game Designers

A primeira sugestatildeo de mudanccedila que fizemos sobre as praacuteticas realizadas no ciclo de desen-volvimento do Scrum altera a dinacircmica do Poker Planning e tem como principal objetivoaumentar a participaccedilatildeo e consequentemente a colaboraccedilatildeo entre os membros da equipede Desenvolvimento durante a reuniatildeo de planejamento do Sprint A ideia central eacute natildeodeixar aspectos multidisciplinares de fora das estimativas atraveacutes de uma dinacircmica quepossibilite que todos participantes (que possuem perfis profissionais diferentes) opinemsobre todos os requisitos apresentados na Sprint Planning

Essa praacutetica nos traz benefiacutecios diretos no planejamento e na concepccedilatildeo dos JD devido adois pontos importantes A nossa proposta adiciona no baralho duas cartas ilustradas nafigura 42 que explicitam a necessidade de examinar os requisitos apresentados de umaforma multidisciplinar Isso diminui a possibilidade do requesito ser subestimado vistoque as diferentes perspectivas estaratildeo representadas nas cartas no momento do showdownAleacutem disso a necessidade de apresentar estimativas para as duas grandes aacutereas que estatildeoenvolvidas no processo de desenvolvimento dos JD evidencia a necessidade de cooperaccedilatildeo

73


A estimativa eacute elaborada colaborativamente Desenvolvedores com perfis diferentes iratildeoconstruir a estimativa a partir dos seus diferentes pontos de vista

A segunda sugestatildeo apresentada nesta pesquisa a Verificaccedilatildeo Multidisciplinar apresen-tada na Figura 47 eacute um ciclo de teste que daacute origem a um novo item de anaacutelise parao documento de Definition of Done e tem como propoacutesito maior corrigir inconsistecircnciasconceituais geradas durante o processo de desenvolvimento dos JD Essa praacutetica de avali-accedilatildeo testa o protoacutetipo desenvolvido no Sprint a partir do ponto de vista de pelo menostrecircs pessoas diferentes (dois desenvolvedores e um jogador) que possuem perspectivas eanseitos distintos Aleacutem disso ela traz a figura do jogador o usuaacuterio final para dentrodo processo de desenvolvimento dos JD

A primeiro benefiacutecio que a Verificaccedilatildeo multidisciplinar nos propicia eacute diminuir ou elimi-nar problemas causados pela individualizaccedilatildeo do trabalho Ao colocar desenvolvedorescom perfis profissionais distintos para analisar o protoacutetipo que foi criado no Sprint noacutescriamos uma grande oportunidade para a equipe de desenvolvimento aperfeiccediloar o pro-duto que estaacute sendo desenvolvido sob um perspectiva multidisciplinar Ou seja problemasgerados pelo fatiamento do trabalho como ajuste da paleta de cores ritmos e batidas datrilha sonora comportamento dos personagens e dos objetos das cenas sincronizaccedilatildeo en-tre a movimentaccedilatildeo dos personagens e efeitos seratildeo observados e corrigidos

Aleacutem disso a anaacutelise que eacute feita pelo jogador na segunda fase da Verificaccedilatildeo multidisci-plinar aproxima a equipe de desenvolvimento do cliente final e do mercado consumidorfato que possibilita o planejamento de novas caracteriacutesticas com base no usuaacuterio final Asnovas possibilidades apontadas pelo jogador podem gerar jogos com mais conteuacutedo valore inovaccedilatildeo para os JD Essas caracteriacutesticas satildeo importantes para o desenvolvimento deprodutos que tecircm a criatividade como base de construccedilatildeo

Acreditamos que as duas praacuteticas sugeridas nesta pesquisa podem ser aplicadas em qual-quer metodologia Aacutegil No entanto ressaltamos que elas satildeo mais aplicaacuteveis ao frameworkde desenvolvimento Scrum devido ao ciclo de amadurecimento constante do processo como foco voltado para o aperfeiccediloamento do produto que estaacute sendo desenvolvido

74

Capiacutetulo Cinco 52 Contribuiccedilotildees diretas

52 Contribuiccedilotildees diretas

Os quatro artefatos apresentado neste trabalho doutoral (o MDJD o Protocolo paraDescriccedilatildeo de JD O Poker Planning colaborativo e a Verificaccedilatildeo Multidisciplinar) tecircmo objetivo de auxiliar o planejamento e desenvolvimento de JD Todo processo de cons-truccedilatildeo desses artefatos foi gradual e teve suporte das experiecircncias vivenciadas durante odesenvolvimento dos trabalhos descritos na Seccedilatildeo 53

O artigo que publiquei juntamente com os meus orientadores foi um marco importantepara construccedilatildeo do MDJD e deu iniacutecio agrave produccedilatildeo dos outros artefatos dessa tese DinizMonteiro amp Carneiro (2016) apresenta um modelo que constroacutei um link direto entre osElementos da Gamificaccedilatildeo e os Objetos de Aprendizagem

Essa pesquisa nasceu da vontade de apresentar uma proposta concreta e praacutetica paraconstruccedilatildeo de Objetos de Aprendizagem Gamificados Diniz Monteiro amp Carneiro (2016)apresenta um modelo que relaciona os conceitos fundamentais dos Objetos de Aprendiza-gem com os componentes que viabilizam o engajamento nos JD Aleacutem disso esse artigoapresenta um passo a passo de como inserir os elementos da gamificaccedilatildeo nos Objetos deAprendizagem

Essa publicaccedilatildeo teve uma grande influecircncia no desenvolvimento desta pesquisa porquedurante a sua realizaccedilatildeo notamos a natureza estrutural que deveriacuteamos aplicar na cons-truccedilatildeo do modelo MDJD Chegamos a essa conclusatildeo porque qualquer sequecircncia definidade passos ou atividades que especifiquem como devemos construir JD limitaraacute a ideli-zaccedilatildeo e concepccedilatildeo deles devido a duas caracteriacutesticas que satildeo impliacutecitas ao processo deconstruccedilatildeo de JD a incerteza e a aprendizagem (KEITH 2010 SALEN ZIMMERMAN2012 SCHELL 2014)

53 Contribuiccedilotildees indiretas

Aleacutem da construccedilatildeo dos artefatos que estatildeo diretamente relacionados com o desenvol-vimento desta pesquisa eu tive a oportunidade de participar da produccedilatildeo de outrostrabalhos acadecircmicos dois JD e trecircs capiacutetulos de livro que contribuiacuteram muito para omeu amadurecimento profissional

75

Capiacutetulo Cinco 53 Contribuiccedilotildees indiretas

Os dois jogos digitais desenvolvidos SimGE 1 e o LIPISpace 2 foram registrados no INPIpelo IFBA devido ao financiamento que a instituiccedilatildeo disponibilizou para desenvolvimentodos JD

O SimGE eacute um JD inspirado nos jogos de simulaccedilatildeo de vida real com o foco voltado paraGestatildeo Escolar Neste jogo o estudante eacute responsaacuteel pelo administraccedilatildeo de uma escolae para obter recursos para equipaacute-la ele precisa responder a uma seacuterie de questotildees queestatildeo relacionadas com o dia a dia da administraccedilatildeo escolar

O LIPISpace eacute um space shooter um jogo de naves especiais no qual o estudante precisadestruir uma seacuterie de asteroides e naves inimigas utilizando descargas eleacutetricas que sofreminfluecircncia de um campo magneacutetico Aleacutem disso no LIPISpace o estudante tem contatocom simuladores que estimulam o estudo e a anaacutelise dos conceitos de campo magneacutetico edo modelo atocircmico de Niels Bohr

Os trecircs capiacutetulos de livros dos quais participei Alves Minho amp Diniz (2014) SantosSouza amp Diniz (2015) Hohenfeld Lapa amp Diniz (2016) retratam momentos diferentesque vivenciei durante o processo de desenvolvimento de minha tese doutoral

O primeiro fala sobre o conceito de gamificaccedilatildeo e apresenta a aplicaccedilatildeo dessas praacuteticas emuma instituiccedilatildeo de ensino da regiatildeo metropolitana de Salvador (ALVES MINHO DINIZ2014) O segundo relata a construccedilatildeo de um site que utiliza a Realidade Aumentada comoferramenta de ensino e aprendizagem da liacutengua brasileira de sinais (SANTOS SOUZADINIZ 2015) Ele eacute resultado de um projeto acadecircmico realizado no IFBA para proverferramentas de ensino para estudantes com necessidades especiais

O terceito capiacutetulo de livro descreve os resultados obtidos em um projeto de cooperaccedilatildeoentre Institutos Federais e o Ministeacuterio de Educaccedilatildeo da Inglaterra o projeto STEM OIFBA aplicou os seus recursos atraveacutes do LIPI no desenvolvimento de experimentosObjetos de Aprendizagem e Jogos Digitais que viabilizavam o ensino de Fiacutesica e Ciecircniasa estudantes do ensino meacutedio (HOHENFELD LAPA DINIZ 2016)

1Jogo Digital Educacional registrado no INPI Nuacutemero de Registro 512015000928-12Jogo Digital Educacional registrado no INPI Nuacutemero de Registro 512016001116-5

76

Capiacutetulo Cinco 54 Contribuiccedilotildees enquanto pesquisador

54 Contribuiccedilotildees enquanto pesquisador

Durante o meu processo de doutoramento (atividades disciplinas e pesquisa) eu tive aoportunidade de coordenar um projeto educacional que me colocou dentro da equipe dedesenvolvimento de um JD o SimGE As experiecircncias que eu vivenciei durante a constru-ccedilatildeo de um JD que precisava apresentar um conteuacutedo educacional e atender aos anseiosde um puacuteblico-alvo foram muito importantes para minha formaccedilatildeo

Aleacutem disso a necessidade de trabalhar com uma equipe multidisciplinar que apresentavaideias diferentes sobre a utilizaccedilatildeo de Jogos Digitais como uma ferramenta educacionalcolocou-me em contato direto com pessoas com formaccedilotildees distintas e diferentes pers-pectivas do processo de ensino e aprendizagem A construccedilatildeo desse JD foi o trabalhocolaborativo mais desafiador que vivenciei

Poreacutem a experiecircncia mais gratificante que tive durante o meu doutoramento foi observarum grupo de profissionais com pouca experiecircncia de desenvolvimento de JD superarlimites e atingir os objetivos que inicialmente noacutes julgavamos improvaacuteveis

55 Atividades Futuras de Pesquisa

O primeiro ponto que precisamos investigar depois da conclusatildeo desta pesquisa douto-ral eacute a aceitaccedilatildeo dos produtos aqui apresentados (modelo protocolo e as duas praacuteticassugeridas) junto ao meio acadecircmico e perante a comunidade de desenvolvedores de JDDesenvolveremos uma pesquisa aplicada a profissionais (professores e desenvolvedores)ligados agrave aacuterea de desenvolvimento e pesquisa de JD para verificar a aderecircncia dos resul-tados gerados nesta pesquisa no ambiente acadecircmico e na induacutestria de desenvolvimentode JD Os resultados gerados pela pesquisa de aceitaccedilatildeo dos produtos apresentados nestetrabalho seratildeo utilizados para aprimorar o MDJD

Aleacutem da accedilatildeo que estaacute diretamente relacionada com o desenvolvimento natural destapesquisa doutoral pretendo atuar na formaccedilatildeo e aperfeiccediloamento de professores (nasLicenciaturas em Computaccedilatildeo Fiacutesica e Matemaacutetica e no Programa de Poacutes-GraduaccedilatildeoLatus Sensu em Educaccedilatildeo Profissional) no Instituto Federal da Bahia utilizando os JogosDigitais como objeto de estudo

77

Apecircndice A

Um exemplo de utitilizaccedilatildeodo Protocolo para descriccedilatildeo

de Jogos Digitais

Neste apecircndice apresentaremos um exemplo de aplicaccedilatildeo do Protocolo para descriccedilatildeo deJogos Digitais Para facilitar o entendimento escolhemos um JD claacutessico e bem conhecidopelo puacuteblico geral

A1 Apresentaccedilatildeo do Jogo Digital Tetris

Tetris eacute um jogo de estrateacutegia criado por Alexey Pajitnov em 1984 Na deacutecada de 1980Pajitnov era um programador e a sua a principal atividade era testar a potencialdade deequipamentos construiacutedos pela antiga Uniatildeo Sovieacutetica Esse trabalho o colocava frenteaos mais novos equipamentos criados pela URSS e em contato direto com os cientistasmais competentes da eacutepoca e com suas ideias (TETRIS 1996)

Esse ambiente produtivo deu a Pajitnov o conjunto de ferramentas e ideias para criarum JD no qual o jogador deveria arranjar as peccedilas de um quebra-cabeccedila que iam caindoem tempo real Pajitnov chamou o jogo de Tetris a junccedilatildeo de duas palavras Tetrapalavra grega que significa quatro e Tennis o esporte que ele mais gostava (TETRIS1996 RABIN 2012)

Atualmente JD Tetris estaacute disponiacutevel nas mais diversas plataformas computacionais(computadores consoles de viacutedeo games viacutedeo games portaacuteteis celulares smartphonesetc) mas o seu lanccedilamento comercial foi feito pela Nintendo em 1989 em uma exposiccedilatildeochamada Consumer Electronics Show em Las Vegas (RABIN 2012)

O grande sucesso do lanccedilamento ocorreu devido a dois fatores o primeiro foi o gecircnero dojogo Tetris cativou e ateacute os dias atuais cativa jogadores de ambos os sexos e de umalarga faixa de idade O segundo motivo foi a plataforma computacional utilizada pelaNintendo O Game Boy ilustrado na Figura A1 eacute um video game portaacutetil lanccedilado em1989 que possibilitou que os jogadores levassem os seus jogos para qualquer lugar Acombinaccedilatildeo desses dois fatores fez do Tetris o passatempo ideal para todos que tivessemum tempo livre entre as suas atividades (RABIN 2012)

78

Apecircndice A A2 Descriccedilatildeo do Tetris

Figura A1 Game Boy console portaacutetil da Nintendo lanccedilado em 1989 Fonte (NINTENDO1989)

A2 Descriccedilatildeo do Tetris

A descriccedilatildeo apresentada na Tabela A1 teraacute como base o jogo Tetris na sua versatildeo originalde 1989 (com sete peccedilas de tipos diferentes) e a plataforma movel Game Boy de 1989conforme ilustrado a Figura A1

79



Dinacircmica 1- Propoacutesito O jogador deveraacute organizar aspeccedilas de quebra cabeccedila quecairatildeo da parte superior dacena sem deixar espaccedilos entreelas

2- Estrateacutegias Gamificadas 1 - O jogador natildeo pode dei-xar a pilha de peccedilas alcanccedilara parte superior da cena 2 - Acada nova fase as peccedilas iratildeo semover mais raacutepido 3 - Exis-tem sete peccedilas com formatosdiferentes

Mecacircnica3- Interatividade O jogador utilizaraacute os bototildees

direcionais para movimentaras peccedilas para os lados e parabaixo O botatildeo Arotacionaas peccedilas a tecla Startiniciaou para o jogo e a tecla Se-lectdaacute ao jogador a opccedilatildeo desair do jogo Tetris pode serjogado por dois jogadores si-multeneamente se os dois con-soles Game Boy estiverem co-nectados via cabo serial

4- Regras 1 - O jogador natildeo pode deixaras linhas incompletas de peccedilasempilhadas chegar ateacute o topoda cena 2 - Quando uma li-nha de peccedilas eacute completada eladesapareceraacute e o jogador ga-nharaacute pontos extra

5- Modelos matemaacuteticos Utilize as seguintes definiccedilotildeesmatemaacuteticas para pontuar se-guindo o nuacutemero de linhas eli-minadas pelo jogador 1 -Uma linha eliminada = (40 (n + 1)) 2 - Duas linhas eli-minadas = (100 (n + 1)) 3 -Trecircs linhas eliminadas = (300 (n + 1)) 4 - Quatro linhaseliminadas = (400 (n + 1))Em todas as quatro definiccedilotildeesnrepresenta o atual niacutevel dedificuldade do jogo O valorde npode variar de 0 a 9

Tabela A1 Descriccedilatildeo do Jogo Digital Tetris Fonte elaborado pelo autor

80



Componentes6- Narrativa Natildeo se aplica Tetris eacute um ca-

sual game7- Fatores graacuteficos As sete peccedilas ilustradas na

Figura A2 seratildeo direcionadase rotacionadas pelos controlesdo console O jogador definiraacutecomo elas se combinaratildeo paraformar uma linha sem espaccedilosde um lado a outro da cena

8- Fatores teacutecnicos O JD seraacute desenvolvido paraexcecutar em um console como processador Custom 8-bitSharp de 419 MHz 8 Kb dememoacuteria RAM 8 Kb de me-moacuteria de viacutedeo e uma paletade cores de dois bits com qua-tro tons de cinza Os JD fi-caratildeo armazenados em cartu-chos do tipo On-CPU-Die de256-bytes e um console podese conectar a outro atraveacutes deum cabo serial conforme ilus-trado na Figura A3 para per-mitir que dois jogadores jogemjuntos um mesmo jogo

Tabela A2 Continuaccedilatildeo da Tabela A1 Fonte elaborado pelo autor

81


Figura A2 As sete peccedilas originais do Jogo Digital Tetris lanccedilado em 1989 Fonte (TETRIS1996)

Figura A3 Conexatildeo entre dois consoles Game Boy Fonte (TETRIS 1996)

82

Referecircncias Bibliograacuteficas

ABT Clark C Serious games [Sl] University Press of America 1987

AacuteGIL Manifesto Manifesto para o desenvolvimento aacutegil de software Disponıvel emhttpmanifestoagil com br Acessado em v 17 2011

ALBINO Raphael Donaire SOUZA Cesar Alexandre De PRADO EdmirParada Vasques Benefiacutecios alcanccedilados por meio de um modelo de gestatildeo aacutegil de projetosem uma empresa de jogos eletrocircnicos Revista de Gestatildeo e Projetos Universidade Novede Julho (UNINOVE) v 5 n 1 p 15 2014

ALVES Lynn Videojogos e aprendizagem mapeando percursos Carvalho A(2012)Aprender na era digital Jogos e Mobile-Learning p 11ndash28 2012

ALVES Lynn RG MINHO Marcelle RS DINIZ Marcelo VC Gamificaccedilatildeo diaacutelogoscom a educaccedilatildeo Gamificaccedilatildeo na educaccedilatildeo Satildeo Paulo Pimenta Cultural p 74ndash972014

BAGNALL Brian On the edge the spectacular rise and fall of Commodore [Sl]Variant Press 2005

BARTLE Richard A Designing virtual worlds [Sl] New Riders 2004

BECK Kent Programaccedilatildeo Extrema (XP) Explicada [Sl] Bookman Editora 2009

BLESS Marc Distributed meetings in distributed teams In SPRINGER InternationalConference on Agile Software Development [Sl] 2010 p 251ndash260

BOEHM Barry W A spiral model of software development and enhancement ComputerIEEE v 21 n 5 p 61ndash72 1988

BRANSFORD John D BROWN Ann L COCKING Rodney R How people learnBrain mind experience and school [Sl] National Academy Press 1999

BRASIL GAME Pesquisa Game Brasil 2016 2015

Pesquisa Game Brasil 2017 2016

CALLOIS Roger Os jogos e os homens a maacutescara e a vertigem Lisboa Cotovia 1990

CAMARGO Caio Interesting complexity Sid meier and the secrets of game designCrossroads ACM v 13 n 2 p 4ndash4 2006

CARNEIRO Tereza Redes de afinidade como estrateacutegia de gestatildeo pedagoacutegica e difusatildeodo conhecimento em cursos na modalidade a distacircncia Faculdade de Educaccedilatildeo 2015

CHOU Yu-Kai Actionable Gamification Beyond Points Badges and Leaderboards[Sl sn] 2015

COHEN Scott Zap The Rise and Fall of Atari [Sl] McGraw-Hill Companies 1984

COHN Mike Agile estimating and planning [Sl] Pearson Education 2005

83

REFEREcircNCIAS BIBLIOGRAacuteFICAS REFEREcircNCIAS BIBLIOGRAacuteFICAS

COSTIKYAN Greg Donrsquot be a vidiot What computer game designers can learn fromnon-electronic games Retrieved September v 26 p 2005 1998

COUGHLAN Paul COGHLAN David Action research for operations managementInternational journal of operations amp production management MCB UP Ltd v 22 n 2p 220ndash240 2002

CRAWFORD Chris The art of computer game design OsborneMcGraw-Hill BerkeleyCA 1984

CSIKSZENTMIHALYI Mihaly Finding flow The psychology of engagement witheveryday life [Sl] Basic Books 1997

DEANGELIS DL GROSS LJ Individual based models and approaches in ecologyconcepts and models [Sl] Routledge Chapman and Hall New York 1992

DETERDING Sebastian et al Gamification using game-design elements in non-gamingcontexts In ACM CHIrsquo11 Extended Abstracts on Human Factors in ComputingSystems [Sl] 2011 p 2425ndash2428

DINIZ Marcelo VC MONTEIRO Roberto LS CARNEIRO Tereza KG Elementosda gamificaccedilatildeo nos objetos de aprendizagem Revista Tecnologias na Educaccedilatildeo p 1ndash122016

DUARTE Luiz Scrum e Meacutetodos Aacutegeis Um Guia Praacutetico [Sl] LuizTools 2016

FARDO Marcelo A gamificaccedilatildeo como meacutetodo estudo de elementos dos games aplicadosem processos de ensino e aprendizagem Dissertaccedilatildeo (Mestrado)ndashUniversidade Caxias doSul Programa de Poacutes-Graduaccedilatildeo em Educaccedilatildeo 2013

FILHO Marisardo Medeiros et al A importacircncia da prototipaccedilatildeo no design de gamesSBCndashProceedings of SBGames 2013

FLEURY Afonso NAKANO Davi CORDEIRO JHDO Mapeamento da induacutestriabrasileira e global de jogos digitais Satildeo Paulo GEDIGamesUSP 2014

FULLERTON Tracy Game design workshop a playcentric approach to creatinginnovative games [Sl] CRC press 2014

GAringSLAND Magne Matre Game mechanic based e-learning A case study Institutt fordatateknikk og informasjonsvitenskap 2011

GEE James Paul What video games have to teach us about learning and literacyComputers in Entertainment (CIE) ACM v 1 n 1 p 20ndash20 2003

GODOY Andreacute BARBOSA Ellen F Game-scrum An approach to agile gamedevelopment Proceedings of SBGames p 292ndash295 2010

GREGORY David Building a Mindset for Rapid Iteration Part 1 The Problem 2010

GRENNING James Planning poker or how to avoid analysis paralysis while releaseplanning Hawthorn Woods Renaissance Software Consulting v 3 2002

GRIMM Volker et al A standard protocol for describing individual-based andagent-based models Ecological modelling Elsevier v 198 n 1 p 115ndash126 2006

84


The odd protocol a review and first update Ecological modelling Elsevierv 221 n 23 p 2760ndash2768 2010

HARRINGTON Dan Harrington on Holdrsquoem Expert Strategy for No-LimitTournaments Volume II the Endgame [Sl] Two Plus Two Publishing LLC 2005v 2

HENSE Jan MANDL Heinz Learning in or with games quality criteria for digitallearning games from the perspectives of learning emotion and motivation theoryIn Proceedings of the IADIS International Conference on Cognition and ExploratoryLearning in the Digital Age [Sl sn] 2012 p 19ndash26

HOHENFELD D P LAPA J M DINIZ M V C Comunidade de praacuteticas de ensinode fiacutesica Fernanda Helena Nogueira-Ferreira Pacircmela Billig Mello-Carpes CristianeMaria Sampaio Forte Cristiane Mansur de Moraes Souza (Org) Caminhos do STEMUm Programa de Educaccedilatildeo Cientiacutefica Relatos e Produtos p 285ndash300 2016

HUIZINGA Johan Homo ludens o jogo como elemento da cultura [Sl] Editora daUniversidade de S Paulo Editora Perspectiva 1931

HUNICKE Robin LEBLANC Marc ZUBEK Robert Mda A formal approach togame design and game research In Proceedings of the AAAI Workshop on Challengesin Game AI [Sl sn] 2004 v 4 p 1

KANODE Christopher M HADDAD Hisham M Software engineering challengesin game development In IEEE Information Technology New Generations 2009ITNGrsquo09 Sixth International Conference on [Sl] 2009 p 260ndash265

KAPP Karl M The gamification of learning and instruction game-based methods andstrategies for training and education [Sl] John Wiley amp Sons 2012

KASURINEN Jussi SMOLANDER Kari What do game developers test in theirproducts In ACM Proceedings of the 8th ACMIEEE International Symposium onEmpirical Software Engineering and Measurement [Sl] 2014 p 1

KEITH Clinton Agile game development with Scrum [Sl] Pearson Education 2010

KHATIB Firas et al Crystal structure of a monomeric retroviral protease solved byprotein folding game players Nature structural amp molecular biology Nature PublishingGroup v 18 n 10 p 1175ndash1177 2011

KNAPP Jake ZERATSKY John KOWITZ Braden Sprint how to solve big problemsand test new ideas in just five days [Sl] Simon and Schuster 2016

KOSTER Raph Theory of fun for game design [Sl] OrsquoReilly Media Inc 2013

LEBLANC Marc et al Mechanics dynamics aesthetics A formal approach to gamedesign lecture at Northwestern University 2004

LUNDGREN Sus BJORK Staffan Game mechanics Describing computer-augmentedgames in terms of interaction In Proceedings of TIDSE [Sl sn] 2003 v 3

MASTROCOLA Vicente Martin Game Design Modelos de negoacutecio e processoscriativos Uma trajetoacuteria do protoacutetipo ao jogo produzido [Sl] Cengage LearningNacional 2015

85


MCGONIGAL Jane Reality is broken Why games make us better and how they canchange the world [Sl] Penguin 2011

Games 2014 URL httpsjanemcgonigalcomplay-me

MELLO Carlos Henrique Pereira et al Pesquisa-accedilatildeo na engenharia de produccedilatildeoproposta de estruturaccedilatildeo para sua conduccedilatildeo Revista Produccedilatildeo SciELO Brasil v 22n 1 p 1ndash13 2012

MICHAEL David R CHEN Sandra L Serious games Games that educate train andinform [Sl] Muska amp LipmanPremier-Trade 2005

MOLOslashKKEN-OslashSTVOLD Kjetil HAUGEN Nils Christian BENESTAD Hans Chris-tian Using planning poker for combining expert estimates in software projects Journalof Systems and Software Elsevier v 81 n 12 p 2106ndash2117 2008

MOORE Gordon E Cramming more components onto integrated circuits reprintedfrom electronics volume 38 number 8 april 19 1965 pp 114 ff IEEE Solid-StateCircuits Newsletter v 3 n 20 p 33ndash35 2006

MUSIL Juergen et al Improving video game development Facilitating heterogeneousteam collaboration through flexible software processes In SPRINGER EuropeanConference on Software Process Improvement [Sl] 2010 p 83ndash94

NEWZOO Top 100 Countries by Game Revenues 2016 Disponiacutevel em lthttpsnewzoocominsightsrankingstop-100-countries-by-game-revenuesgt Acesso em 13mar 2016

NINTENDO A Histoacuteria da Nintendo 1989 Disponiacutevel em lthttpswwwnintendoptA-empresaHistoria-da-NintendoGame-BoyGame-Boy-627031htmlgt Acesso em20 mai 2017

ORACLE Distributed Planning Poker Integrating IBM Rational Team Concertand Google Wave for distributed effort estimation 2014 Disponiacutevel em lthttpjazooncomhistoryPortals0Contentslideswe_a3_1600-1650_georgpdfgt Acessoem 20 mai 2017

PARLETT David Sidney The Oxford history of board games [Sl] Oxford UniversityPress USA 1999

PAULK Mark C Extreme programming from a cmm perspective IEEE software IEEEv 18 n 6 p 19ndash26 2001

PETRILLO Faacutebio et al Houston we have a problem a survey of actual problems incomputer games development In ACM Proceedings of the 2008 ACM symposium onApplied computing [Sl] 2008 p 707ndash711

PETRY Arlete dos Santos et al Paracircmetros estrateacutegias e teacutecnicas de anaacutelise de jogo ocaso a mansatildeo de queliacutecera In Simpoacutesio Brasileiro de Jogos e Entretenimento DigitalSatildeo Paulo SP Brasil [sn] 2013

PINTEREST O cataacutelogo mundial de ideacuteias 2010 Disponiacutevel em lthttpsbrpinterestcompin424112489882827959gt Acesso em 20 mai 2017

POPPENDIECK Mary POPPENDIECK Tom Implementando o desenvolvimentoLean de Software do conceito ao dinheiro [Sl] Bookman Editora 2009

86


RABIN Steve Introduccedilatildeo ao desenvolvimento de games Satildeo Paulo Cengage Learning2012

RAILSBACK Steven F GRIMM Volker Agent-based and individual-based modeling apractical introduction [Sl] Princeton university press 2011

ROUSE Richard Game design Theory and practice [Sl] Jones amp Bartlett Learning2010

ROYCE Winston W Managing the development of large software systems In LOSANGELES proceedings of IEEE WESCON [Sl] 1970 v 26 n 8 p 328ndash338

SALEN Katie ZIMMERMAN Eric Regras do jogo fundamentos do design de jogosSatildeo Paulo Blucher v 1 p 69 2012

SANTOS L C M SOUZA A C S DINIZ M V C Desenvolvimento de um portalde animaccedilotildees em realidade aumentada para o processo de ensino-aprendizagem da liacutenguabrasileira de sinais Hipermiacutedia e interdisciplinaridade na geraccedilatildeo de conhecimentop 154 2015

SCHANK Roger C Dynamic memory revisited [Sl] Cambridge University Press1999

SCHELL Jesse The Art of Game Design A book of lenses [Sl] CRC Press 2014

SCHETINGER Victor et al User stories as actives for game developmentSBC-Proceedings of SBGames 2011 p 53 2011

SCHILD Jonas WALTER Robert MASUCH Maic Abc-sprints adapting scrum toacademic game development courses In ACM Proceedings of the Fifth InternationalConference on the Foundations of Digital Games [Sl] 2010 p 187ndash194

SCHWABER Ken SUTHERLAND Jeff The definitive guide to scrum the rules of thegame Recuperado de httpwww scrumguides orgdocsscrumguidev1scrum-guide-us pdf 2013

SEBRAE Boletin 2014 Grandes players e pequenos negoacutecios de Games 2014 Disponiacutevelem lthttpsebrae2014sebraecombrSebraeSebrae202014Boletins2014_06_06_BO_Economia_Criativa_Grandes_players_pequenos_negC3B3cios_de_Gamespdfgt Acesso em 08 jul 2016

SHARP Helen ROGERS Y PREECE J Design de interaccedilatildeo aleacutem da interaccedilatildeohomem-computador Artmed 2005

SKINNER Burrhus Frederic Science and human behavior [Sl] Simon and Schuster1953

SOMMERVILLE Ian Software engineering [Sl] Pearson 2010

STARFIELD Anthony M Qualitative rule-based modeling BioScience JSTOR v 40n 8 p 601ndash604 1990

SUITS Bernard The Grasshopper- Games Life and Utopia [Sl] Broadview Press2014

SUTHERLAND Jeff Scrum-a arte de faze o dobro de trabalho na metade do tempo[Sl] Leya 2016

87


TETRIS Tetris Official Site 1996 Disponiacutevel em lthttptetriscomgt Acesso em20 jan 2017

THIOLLENT Michel Metodologia da pesquisa-accedilatildeo In Metodologia da pesquisa-accedilatildeo[Sl] Cortez 2011

TRIPP David Pesquisa-accedilatildeo uma introduccedilatildeo metodoloacutegica Educaccedilatildeo e pesquisaSciELO Brasil v 31 n 3 p 443ndash466 2005

UCHMAŃSKI Janusz GRIMM Volker Individual-based modelling in ecology whatmakes the difference Trends in Ecology amp Evolution Elsevier v 11 n 10 p 437ndash4411996

WERBACH Kevin HUNTER Dan For the win How game thinking can revolutionizeyour business [Sl] Wharton Digital Press 2012

WESTBROOK Roy Action research a new paradigm for research in production andoperations management International Journal of Operations amp Production ManagementMCB UP Ltd v 15 n 12 p 6ndash20 1995

WILKINSON Phil A brief history of serious games In Entertainment Computing andSerious Games [Sl] Springer 2016 p 17ndash41

88





Tese de doutorado




Co-orientadora Prof a Dra Tereza Kelly Gomes Carneiro

Julho de 2017










2017

NDI - 04



103 f il color






CDD 62000113










C U SENAI Bahia


UNCISAL


C U SENAI Bahia


C U SENAI Bahia


UNEB


UNEB


Agradecimentos









5

Resumo



i

Abstract



ii

Sumaacuterio











iii


Referecircncias 83

iv

Lista de Tabelas







v

Lista de Figuras










vi



vii

Lista de Siglas


viii

Capiacutetulo Um






1







2







3







4







5



12 Objetivo










6



14 Pressupostos














7








8






9







10






11











12




13

Capiacutetulo Dois


Desenvolvimento






14







15








16









17







18












19







20








21







22







23







24








25







26






27





28






29















30







31






32





27 O protocolo ODD




33






34








35





36







37





38





39






40













29 O modelo MDA


41







42












43







44






45





311 O objetivo



46







47






48






49








50







51




52














53









54








55












56









57










58






59








60





61




62






63








64







65





66






67



autor




68






69







70



71

Capiacutetulo Cinco



51 Conclusotildees




72







73







74









75









76









77

Apecircndice A


de Jogos Digitais







78





79










80








81




82





















83




















84


















85


















86




















87









88










2017

NDI - 04



103 f il color






CDD 62000113










C U SENAI Bahia


UNCISAL


C U SENAI Bahia


C U SENAI Bahia


UNEB


UNEB


Agradecimentos









5

Resumo



i

Abstract



ii

Sumaacuterio











iii


Referecircncias 83

iv

Lista de Tabelas







v

Lista de Figuras










vi



vii

Lista de Siglas


viii

Capiacutetulo Um






1







2







3







4







5



12 Objetivo










6



14 Pressupostos














7








8






9







10






11











12




13

Capiacutetulo Dois


Desenvolvimento






14







15








16









17







18












19







20








21







22







23







24








25







26






27





28






29















30







31






32





27 O protocolo ODD




33






34








35





36







37





38





39






40













29 O modelo MDA


41







42












43







44






45





311 O objetivo



46







47






48






49








50







51




52














53









54








55












56









57










58






59








60





61




62






63








64







65





66






67



autor




68






69







70



71

Capiacutetulo Cinco



51 Conclusotildees




72







73







74









75









76









77

Apecircndice A


de Jogos Digitais







78





79










80








81




82





















83




















84


















85


















86




















87









88

NDI - 04



103 f il color






CDD 62000113










C U SENAI Bahia


UNCISAL


C U SENAI Bahia


C U SENAI Bahia


UNEB


UNEB


Agradecimentos









5

Resumo



i

Abstract



ii

Sumaacuterio











iii


Referecircncias 83

iv

Lista de Tabelas







v

Lista de Figuras










vi



vii

Lista de Siglas


viii

Capiacutetulo Um






1







2







3







4







5



12 Objetivo










6



14 Pressupostos














7








8






9







10






11











12




13

Capiacutetulo Dois


Desenvolvimento






14







15








16









17







18












19







20








21







22







23







24








25







26






27





28






29















30







31






32





27 O protocolo ODD




33






34








35





36







37





38





39






40













29 O modelo MDA


41







42












43







44






45





311 O objetivo



46







47






48






49








50







51




52














53









54








55












56









57










58






59








60





61




62






63








64







65





66






67



autor




68






69







70



71

Capiacutetulo Cinco



51 Conclusotildees




72







73







74









75









76









77

Apecircndice A


de Jogos Digitais







78





79










80








81




82





















83




















84


















85


















86




















87









88









C U SENAI Bahia


UNCISAL


C U SENAI Bahia


C U SENAI Bahia


UNEB


UNEB


Agradecimentos









5

Resumo



i

Abstract



ii

Sumaacuterio











iii


Referecircncias 83

iv

Lista de Tabelas







v

Lista de Figuras










vi



vii

Lista de Siglas


viii

Capiacutetulo Um






1







2







3







4







5



12 Objetivo










6



14 Pressupostos














7








8






9







10






11











12




13

Capiacutetulo Dois


Desenvolvimento






14







15








16









17







18












19







20








21







22







23







24








25







26






27





28






29















30







31






32





27 O protocolo ODD




33






34








35





36







37





38





39






40













29 O modelo MDA


41







42












43







44






45





311 O objetivo



46







47






48






49








50







51




52














53









54








55












56









57










58






59








60





61




62






63








64







65





66






67



autor




68






69







70



71

Capiacutetulo Cinco



51 Conclusotildees




72







73







74









75









76









77

Apecircndice A


de Jogos Digitais







78





79










80








81




82





















83




















84


















85


















86




















87









88


Agradecimentos









5

Resumo



i

Abstract



ii

Sumaacuterio











iii


Referecircncias 83

iv

Lista de Tabelas







v

Lista de Figuras










vi



vii

Lista de Siglas


viii

Capiacutetulo Um






1







2







3







4







5



12 Objetivo










6



14 Pressupostos














7








8






9







10






11











12




13

Capiacutetulo Dois


Desenvolvimento






14







15








16









17







18












19







20








21







22







23







24








25







26






27





28






29















30







31






32





27 O protocolo ODD




33






34








35





36







37





38





39






40













29 O modelo MDA


41







42












43







44






45





311 O objetivo



46







47






48






49








50







51




52














53









54








55












56









57










58






59








60





61




62






63








64







65





66






67



autor




68






69







70



71

Capiacutetulo Cinco



51 Conclusotildees




72







73







74









75









76









77

Apecircndice A


de Jogos Digitais







78





79










80








81




82





















83




















84


















85


















86




















87









88

Agradecimentos









5

Resumo



i

Abstract



ii

Sumaacuterio











iii


Referecircncias 83

iv

Lista de Tabelas







v

Lista de Figuras










vi



vii

Lista de Siglas


viii

Capiacutetulo Um






1







2







3







4







5



12 Objetivo










6



14 Pressupostos














7








8






9







10






11











12




13

Capiacutetulo Dois


Desenvolvimento






14







15








16









17







18












19







20








21







22







23







24








25







26






27





28






29















30







31






32





27 O protocolo ODD




33






34








35





36







37





38





39






40













29 O modelo MDA


41







42












43







44






45





311 O objetivo



46







47






48






49








50







51




52














53









54








55












56









57










58






59








60





61




62






63








64







65





66






67



autor




68






69







70



71

Capiacutetulo Cinco



51 Conclusotildees




72







73







74









75









76









77

Apecircndice A


de Jogos Digitais







78





79










80








81




82





















83




















84


















85


















86




















87









88


5

Resumo



i

Abstract



ii

Sumaacuterio











iii


Referecircncias 83

iv

Lista de Tabelas







v

Lista de Figuras










vi



vii

Lista de Siglas


viii

Capiacutetulo Um






1







2







3







4







5



12 Objetivo










6



14 Pressupostos














7








8






9







10






11











12




13

Capiacutetulo Dois


Desenvolvimento






14







15








16









17







18












19







20








21







22







23







24








25







26






27





28






29















30







31






32





27 O protocolo ODD




33






34








35





36







37





38





39






40













29 O modelo MDA


41







42












43







44






45





311 O objetivo



46







47






48






49








50







51




52














53









54








55












56









57










58






59








60





61




62






63








64







65





66






67



autor




68






69







70



71

Capiacutetulo Cinco



51 Conclusotildees




72







73







74









75









76









77

Apecircndice A


de Jogos Digitais







78





79










80








81




82





















83




















84


















85


















86




















87









88

Resumo



i

Abstract



ii

Sumaacuterio











iii


Referecircncias 83

iv

Lista de Tabelas







v

Lista de Figuras










vi



vii

Lista de Siglas


viii

Capiacutetulo Um






1







2







3







4







5



12 Objetivo










6



14 Pressupostos














7








8






9







10






11











12




13

Capiacutetulo Dois


Desenvolvimento






14







15








16









17







18












19







20








21







22







23







24








25







26






27





28






29















30







31






32





27 O protocolo ODD




33






34








35





36







37





38





39






40













29 O modelo MDA


41







42












43







44






45





311 O objetivo



46







47






48






49








50







51




52














53









54








55












56









57










58






59








60





61




62






63








64







65





66






67



autor




68






69







70



71

Capiacutetulo Cinco



51 Conclusotildees




72







73







74









75









76









77

Apecircndice A


de Jogos Digitais







78





79










80








81




82





















83




















84


















85


















86




















87









88

Abstract



ii

Sumaacuterio











iii


Referecircncias 83

iv

Lista de Tabelas







v

Lista de Figuras










vi



vii

Lista de Siglas


viii

Capiacutetulo Um






1







2







3







4







5



12 Objetivo










6



14 Pressupostos














7








8






9







10






11











12




13

Capiacutetulo Dois


Desenvolvimento






14







15








16









17







18












19







20








21







22







23







24








25







26






27





28






29















30







31






32





27 O protocolo ODD




33






34








35





36







37





38





39






40













29 O modelo MDA


41







42












43







44






45





311 O objetivo



46







47






48






49








50







51




52














53









54








55












56









57










58






59








60





61




62






63








64







65





66






67



autor




68






69







70



71

Capiacutetulo Cinco



51 Conclusotildees




72







73







74









75









76









77

Apecircndice A


de Jogos Digitais







78





79










80








81




82





















83




















84


















85


















86




















87









88

Documents

UmmodeloconceitualdeDesenvolvimentodeJogos Digitais