Escola Universitària d’Enginyeria Tècnica de Telecomunicació La Salle

Treball Final de Grau

Grau en Enginyeria Multimèdia

UNDERNET

Alumne Professor Ponent Joan Vidal López Marc Antonijuan Tresens

ACTA DE L'EXAMEN DEL TREBALL FI DE CARRERA

Reunit el Tribunal qualificador en el dia de la data, l'alumne

D. Joan Vidal López va exposar el seu Treball de Fi de Carrera, el qual va tractar sobre el tema següent:

UnderNET

Acabada l'exposició i contestades per part de l'alumne les objeccions formulades pels Srs. membres del tribunal, aquest valorà l'esmentat Treball amb la qualificació de

Barcelona,

VOCAL DEL TRIBUNAL VOCAL DEL TRIBUNAL

PRESIDENT DEL TRIBUNAL Agraïments

M’agradaria dedicar aquest projecte a aquelles persones que al llarg d’aquest temps han col·laborat ja sigui amb paciència, ajuda o temps hagi pogut realitzar-se. Al meu pare, la meva mare i germans pel seu suport innestimable.

I especialment a aquelles persones que no han pogut veure’l finalitzat: als meus avis. A Gregorio que, juntament amb el meu pare, m’han transmés la passió per la tecnologia i a Juan, el primer “enginyer” de la familia. UnderNET

ÍNDEX

RESUM ...... 3

1. INTRODUCCIÓ ...... 4

2. ESTAT DE L’ART ...... 7

3. EDUTAIMENT ...... 10

4. DISSENY DEL JOC ...... 13 4.1 CONSIDERACIONS PRÈVIES ...... 13 Quin tipus de joc es vol realitzar ...... 13 4.2 GAME DESIGN DOCUMENT ...... 16 4.3 GDD v1 ...... 17 4.4 GDD v2 ...... 18 GAME DESING DOCUMENT – UNEDERNET v2 ...... 19

5. CREACIÓ DE L’ART ...... 27 5.1 INSPIRACIÓ ...... 27 5.2 ART WORK ...... 29 MOODBOARD ...... 29 PALETA DE COLORS ...... 29 GUI ...... 30 5.3 DISSENYS FINALS ...... 31 GUIs ...... 31 MODELATGES 3D...... 33 TEXTURES ...... 39

6. IMPLEMENTACIÓ ...... 41 6.1 DEFINICIÓ TECNOLOGIA ...... 41 COMPARATIVA MOTORS GRÀFICS ...... 41 ELECCIÓ MOTOR GRÀFIC ...... 46 6.2 ENTORN DE DESENVOLUPAMENT ...... 47 IDE UNITY ...... 47 MICROSOFT VISUAL STUDIO 2012 ...... 48 6.3 GESTIÓ DEL PROJECTE AMB UNITY...... 49 Scripts ...... 49 Jerarquia del projecte ...... 49 6.4 DESENVOLUPAMENT DE NIVELLS ...... 51 MAZE: NIVELL 1 ...... 51 CITY: NIVELL 2 ...... 53

1 UnderNET

DEVICE: NIVELL 3 ...... 56 MENU I EXPLICATIUS ...... 57 6.5 EXPORTACIÓ ...... 58 6.6 TECNOLOGIES NO APLICADES...... 59 GENERADOR DE LABERINTS ...... 59 PATHFINDING ...... 60 XML / DLLs ...... 62

7. RESULTATS ...... 64

8. CONCLUSIONS ...... 65

9. LÍNIES DE FUTUR ...... 67

10. ESTUDI DE COSTOS...... 69

ÍNDEX DE FIGURES ...... 70

BIBLIOGRAFIA ...... 72

ANNEX ...... 74

2 UnderNET

RESUM

En un món cada cop més interactiu els mètodes tradicionals d’ensenyament poden no satisfer les necessitats de l’estudiant en la seva totalitat. Aquest projecte pretén oferir una eina didàctica que permeti ajudar a assentar coneixements acadèmics, els quals es centraran en l’àmbit de la telemàtica. El resultat és l’estructura bàsica d’un videojoc que permetrà aprendre i aprofundir en els coneixements de l’estudiant, mentre interactua amb el seu entorn real. Per dur-ho a terme s’ha recorregut les diverses fases tradicionals de la creació dels videojocs des del seu disseny fins la seva implementació, sempre partint de la vessant didàctica.

En un mundo cada vez más interactivo los métodos educativos tradicionales pueden no satisfacer las necesidades del estudiante en su totalidad. Este proyecto pretende ofrecer una herramienta didáctica que permita ayudar a asentar conocimientos académicos, los cuales se centrarán en el ámbito de la telemática. El resultado es la estructura básica de un videojuego que permitirá aprender y profundizar en los conocimientos del estudiante, mientras interactúa con su entorno real. Para su realización se han recorrido las diversas fases tradicionales en la creación de videojuegos desde su diseño a su implementación, siempre partiendo de la perspectiva didáctica.

In an increasingly interactive world, traditional educational methods may not meet students’ needs completely. This project aims to provide an educational tool which enables us to help to consolidate knowledge focused on the field of telematics. The result is the basic structure of a video game that will allow students to learn and go deeply into their own knowledge, while interacting with their real environment. The game has been developed following several traditional video game creation phases from its design to its implementation, always starting from the educational point of view.

3 UnderNET

1. INTRODUCCIÓ

El grup de Telemàtica conjuntament amb el grup de Human Computer Interaction del Campus Barcelona de La Salle (Universitat Ramon Llull) en el seu esperit d’innovació van veure la necessitat de buscar noves vies educatives, en aquest cas dins el marc de la telemàtica. Fruit d’aquest interès es va plantejar com a possible projecte final de carrera; el qual havia de combinar la tecnologia dels videojocs com a mètode didàctic.

Un primer factor a tenir en compte és el perfil de les persones que juguen a videojocs. El marc que se’ns mostra es força escaient també, segons un estudi desenvolupat per ISFE (Interactive Software Industry) que representa als editors de videojocs, publicat el novembre del 2012 [1]:

Figura 1: Perfil de jugadors a Espanya l'any 2012

A través de la Figura 1: Perfil de jugadors a Espanya l'any 2012 observem que un 40% de la població entre 16 i 64 anys ha jugat a videojocs els últims 12 mesos, i molts especialment les franges dels 20-44 anys. Això ens indica que ens estariem movent per una franja d’edat atreta pels videojocs, reforçant l’idea de la idoneïtat del projecte. Així doncs, aquest projecte en tota la seva magnitud té com a finalitat presentar una solució educativa que permeti als estudiants assolir un conjunt de coneixements sobre telemàtica de la manera més atractiva possible. Es va trobar escaient la interrelació de diversos perfils d’estudiants que puguin complementar-se en funció de l’especialitat en cadascuna de les seves àrees, perque assolir un videojoc que atorguia l’estudiant les eines necessàries per ajudar a assolir els coneixements de l’assignatura de telemàtica.

S’ha buscat aconseguir-ho través del concepte d’Edutaiment (capítol 3: Edutaiment), que finalment s’ha vist reflexat en forma de prototip d’un videojoc. Ha estat estructurat en 3 apartats: telemàtic, d’àudio i interactiu; amb la finalitat d’assolir un resultat més acurat ja

4 UnderNET

que permet una especialització en cadascún d’aquests apartats, assignant-los a especialistes de cada camp. L’apartat de telemàtica es centra en l’anàlisi de la xarxa al en el que l’usuari està connectat i la comunicació amb l’aplicació pel transvasament de les dades aconseguides. En el cas de l’àudio s’encarregarà de la planificació, generació i aplicació de sons i músiques que s’apliquin al joc.

Pel que fa aquest projecte en concret fa referència al mòdul interactiu, que té com objectiu principal generar una primera versió del videojoc. Aquest videojoc hauria de tenir aquestes característiques:

 La versió ha de ser jugable.  Complir amb els requisits i conceptes d’Edutaiment.  Ha de pivotar respecte la temàtica de telemàtica, la xarxa ha de ser l’epicentre del projecte.  La xarxa real s’ha de reflexar al joc.  Permetre la integració dels altres dos mòduls que resten.  Permetre l’escalabilitat.

Com es comentava des d’un inici, té una perspectiva escalable. El “joc” no queda tancat sinó que estarà obert per a futures expansions. Això implica que en el disseny del joc s’ha de preveure que es puguin afegir nous mètodes didàctics i de joc, sense que canviï l’esència d’aquesta versió.

Donada la magnitud i la diferència de camps que es composa el projecte, la tutorització del projecte es comparteix amb dos ponents, per aportar suport a les diverses àrees:  Àrea Telemàtica: Jaume Abella  Desenvolupament de videojocs: Marc Antonijoan

Aquesta memòria descriu el desenvolupament de la primera versió d’un videojoc anomenat UnderNET. El document s’estructura en quatre grans blocs: els coneixements previs, la prepoducció, la producció i el resultat. El primer bloc conté els apartats de l’estat de l’art (apartat 1) i Edutaiment (apartat 2). En l’apartat de l’Estat de l’art s’expliquen les iniciatives similars, fent un petit anàlisi de les seves mancances i èxits. En el següent apartat d’Edutaiment es mostra a què fa referència aquest concepte i com assolir-l’ho. El segon bloc, la preproducció, s’explicarà per mitjà de l’apartat de Disseny del joc (apartat 3) on es mostrarà com s’ha dissenyat el joc i el perquè de les decisions preses.

5 UnderNET

El tercer bloc estarà representat pels apartats Creació de l’art (apartat 4), os s’explica la creació d’aquell apartat gràfic i artístic, i la Implementació (apartat 5) on es veu la realització de tot l’apartat més tècnic. Finalment en el quart bloc es mostrarà el resultat per mitjà de l’apartat 6 Resultats, un anàlisi dels mateixos amb Conclusions (apartat 7) i acabant amb unes guies de com pot evolucionar el projecte amb Línies de futur (apartat 8).

6 UnderNET

2. ESTAT DE L’ART

L’estat de l’art fa referència a l’anàlisi de quines són les solucions que s’han proposat prèviament per resoldre la nostra problemàtica. En el cas d’aquest projecte: proporcionar un aprenentatge i afermar els coneixements d’una manera atractiva. La cerca ha consistit en analitzar un conjunt d’aplicacions amb objectius comuns. Els principals intents en aquest camp didàctic han correspost a CISCO NetAcad [2]. CISCO NetAcad és una iniciativa engegada per la companyia Cisco Systems, que té com a finalitat oferir cursos i certificats sobre xarxes. Dintre de la seva plataforma d’internet s’hi pot trobar un apartat amb diverses tentatives per utilitzar jocs per aprendre. Els resultats obtinguts són essencialment jocs del perfil Quizz, és a dir, pregunta-resposta. Després d’analitzar aquests jocs s’ha arribat a les següents conclusions respecte els perfils Quizz:

Elements positius:  Gran contingut didàctic, ja que permet abarcar una gran quantitat de materia i ofereix la possibilitat de focalitzar d’una directe. Ofereix un gran control sobre el material que es vol aprendre.

Elements negatius:  Aburrits, al no deixar de ser un tipus test que es podria realitzar sense necessitat de mostrar-lo en forma de joc. No oferieix una alternativa lúdica real.

Figura 2: Fotograma d'un joc de Cisco amb perfil Quizz

7 UnderNET

També es van trobar intents més innovadors, com l’Edge Quest [3], o el Binary Game [4] entre d’altres, que inclouen les seves versions per a dispositius mòbils. Edge Quest ofereix una nova perpectiva per mostrar el funcionament de l’enviament de paquets a través de la xarxa. Consiteix en portar una nau que es desplaça a una velocitat creixent per un túnel, durant el seu transcurs haurà de recollir els diversos paquets, mentres esquiva els paquets malmesos. Joc de mecànica clàssica però que funciona força bé, ja que s’ha aconseguit un bon equilibri des del punt de vista de jugabilitat.

Figura 3: Fotograma del joc “Edge Quest 2”

Pel que fa a Binary Game, la seva mecànica és encara més simple, ja que consisteix en traduïr de números de decimal a binari i a l’inrevés, amb l’objectiu de resoldre el màxim número de traduccions en el mínim temps possible per obtenir una bona puntuació. Aquest joc malgrat la seva simplicitat és molt eficaç, ja que assoleix l’objectiu d’agilitzar el càlcul a la vegada que el temps afegeix una motivació i evita que es faci tediós.

Figura 4: Fotograma del joc Binary Game

Elements positius:  Atractius i entretinguts, ja que ofereixen una alternativa a els típique preguntes- respostes, oferint un entreteniment real.

8 UnderNET

 Rejugabilitat, permeten que els jugadors estguis atrets a tornar-hi a jugar un cop s’ha finalitzat la partida.  Exportació a dispositius mòbils, permeten que puguin ser jugats en qualsevol moment

Elements negatius:  Conceptes educatius molt específics, es focalitzen massa en una temàtica en concret, pel que només es pot aprendre una porció molt petita del temari.

Després de l’anàlisi de totes les alterantives que se’ns ofereixen comprovem que realment no s’aproximen prou al concepte d’entreteniment educatiu que es pretenem oferir, ja que tenim un enfoc més aproximat als jocs tridimensionals que trobem en les plataformes actuals, i es busca un marc més general que pugui contenir més conceptes teòrics. Es considera que ha de ser més atraient pel jugador, per això es vol aplicar un entorn 3D que aporti més modernitat i que sigui FPS (primera persona) per donar una sensació de més implicació.

9 UnderNET

3. EDUTAIMENT

Edutaimant és la contracció de dues paraules angleses Education + Entertaiment (Educació + Entreteniment), i fa referència al concepte de tot aquell contingut d’entreteniment amb una finalitat didàctica, sempre i quant assoleixi un alt grau d’eficàcia en ambdós camps.

L’edutaiment no és un concepte nou, malgrat que l’auge de la informàtica ha propiciat el seu creixement i evolució.

A la dècada dels ‘80 amb la popularització dels ordinadors personals, el consum de software va augmentar proporcionant a educadors i informàtics un nou mitjà per ajudar als nens a aprendre i produint el naixement de la industria del software educacional. Com són els exemples de Math Blaster [5] i Cómo funcionan las cosas [6].

Figura 5: Fotograma “Math Blaster”

Figura 6: Fotograma “Cómo funcionan las cosas”

En les següents dècades el concepte ha anat evolucionat i diversificant fins arribar en una de les seves branques a la que actualment es coneix com Serious Games.

10 UnderNET

Els Serious Games és la denominació que ha rebut aquelles aplicacions que utilitzen la tecnologia dels videojocs amb una finalitat que va més enllà del pur entreteniment. Comunment utilitzades per a camps tant diversos com defensa, enginyeria civil, medicina...

Un exemple senzill seria un simulador: tenim un estudiant que ha d’aprendre a soldar, i per evitar el cost innecessari de les primeres soldadures i perill de cremades utilitza el simulador. Aquest simulador utilitza tecnologia de videojocs, que proporciona les eines per recrear una realitat virtual que li permeti practicar. Aquesta metodologia pot produir una sensació per part de l’usuari que està jugant pel que pot fer-li menys tediosa aquest aprenentatge.

Figura 7: Exemple de serious game

El fet d’utilitzar el joc com a element educatiu permet aprofitar-se d’un estat mental comú als videojocs anomenat flux. Segons Weinberg y Gould (1996) [7] el flux és:

“Una sensació de plenitud i d’estar totalment implicat en una tasca, joc o activitat esportiva, sempre que les habilitats de la persona corresponguin al desafiament, el que facilita un rendiment òptim. A mètode de resum, las característiques de la sensació de fluxe són: completa absorció en l’activitat (tot el que hi ha al cap de l’esportista és el joc), fusió de l’acció i la conciència (no penses en les accions, surten soles), pèrdua de la autoconciència (t’oblides de tu mateix), pèrdua del interès en recompenses o objetius externs a l’activitat (gaudeixes amb el joc en si mateix) i moviments sense esforç (anar amb el pilot automàtic i no voler parar).”

Conceptes clau per entendre el potencial que pot arribar a tenir aprendre mentres jugues. Així doncs analitzem com es comporta el mercat amb jocs pensats amb clau edutainment

Com s’observa a continuació a la figura 8 [8] el percentatge dedicat per a universitats i estudis superirors és molt baix, fet que ens indica que és un mercat per explotar. Aquesta manca de jocs seriosos per edats universitaries és degut a que requereixen un grau de complexitat i que malgrat la mentalitat poc a poc ha anat canviant els videojocs encara poden relacionar-se com un entreteniment per a nens.

11 UnderNET

TARGET SERIOUS GAMES

Escola Primaria 5% 16% 40% Preescolar i anteriors

Universitats, adults i séniors 39% Educació Secundaria

Figura 8: Gràfica representativa dels percentatges de jocs basats en l'edutainment

12 UnderNET

4. DISSENY DEL JOC

El disseny del joc és el primer pas pel desenvolupament del mateix. Consisteix en preveure totes aquelles necessitats que caldran resoldre per al moment de la seva implementació, així com prendre les decisions que corresponen a estructura i mètodes del joc.

Per a dur a terme aquest disseny es va fonamentar en 2 fases:

 La primera va consistir en un anàlisi de l’estat de l’art (explicat en el punt 1 de la memòria) d’aquí vam extreure les conclusions que ens van portar a realitzar una primera aproximació al que volíem que fos el nostre joc. Que es va plasmar en forma Pitch1 (es pot trobar a l’Annex) per a l’anàlisi junt amb els tutors.  La segona va ser la definició de la totalitat del joc. Per realitzar-se es va dur a terme mitjançant els criteris del Game Design Document (GDD), on es pot trobar tot allò referent al disseny.

4.1 CONSIDERACIONS PRÈVIES

Abans d’intentar desenvolupar un joc, cal plantejar-se una sèrie de qüestions.

Quin tipus de joc es vol realitzar S’ha decidit realitzar un joc educatiu, amb el que coneixem que la finalitat és facilitar una sèrie de coneixements, no obstant a l’hora de crear un videojoc és necessari establir-ne el gènere.

Gèneres de videojocs Actualment és força difícil catalogar els videojocs en un únic estil, ja que solen ser un híbrid de diversos gèneres. Malgrat això, podem classificar en quatre grans blocs:

 Aventura: aquell gènere en el qual el jugador ha de resoldre un conjunt de trencaclosques interactuant amb l’entorn. Podem trobar evolucions i/o

1 Referència a una presentació verbal concisa d’un producte audiovisual, amb l’objectiu de buscar finançament.

13 UnderNET

especialitzacions com: rol (Final Fantasy), aventures gràfiques (Monkey Island), aventures conversacionals (Adventure2)...  Acció: són aquells que requereixen per part del jugador reflexos i/o precisió per superar una sèrie d’obstacles. Probablement és el gènere que pot arribar a englobar un major nombre de jocs. Aquí podem trobar jocs del tipus: lluita (Street Fighter), plataformes (Super Mario Bros), dispars (Call of Duty)...  Simulació: són aquells que pretenen oferir una representació virtual, d’algun element de la realitat. Aquí podem trobar: simulació de vehicles (Flight Simulator, Gran Turismo), simulació de vida (The Sims), simulació de gestió/Dèus (Age of Empires)...  Altres: són tots aquells que tenen estructures diferents com per exemple un quizz (Buzz).

Selecció gènere A l’hora d’escollir el gènere es va escollir quelcom que ofereixi una experiència el més immersiva possible i que aprofités les experiències prèvies com a usuari de videojocs. Es pretén aquesta experiència cercant aquell component afavoreixi una major implicació de l’usuari en el moment de jugar-hi, tornant al concepte de flux prèviament esmentat (apartat Edutaiment). Es vol defugir del format pregunta-resposta ja que s’aproxima massa al format d’un exercici tradicional de classe, i no ens aporta cap nova motivació. El joc ha de ser prou lúdic perquè l’usuari gaudeixi fins el punt que no s’adoni que està aprenent teoria. Per aquest motius s’escull un joc d’aventures, que contingui elements d’acció, i que és desenvolupi en primera persona i en 3D.

Selecció plataforma D’altra banda també calia escollir quina era la plataforma mitjançat es volia distribuir el joc. És una decisió crítica i que s’ha de reflexionar amb seriositat donat que influirà directament en l’experiència. Els comandaments i accions no són els mateixos, i l’elecció pot donar llibertat o limitar-ne l’ús.

Es va decidir que fos per a PC i sistema operatiu Windows. Aquesta decisió ve donada perquè es volia abastar a la major quantitat de gent possible, pel que ens interessava una plataforma el més utilizada possible, com s’explica a continuació.

Analitzant les dades obtingudes a través de de NETMARKETSHARE (Market Share Statistics for Internet Technologies) [9], observem (figura 9) que a nivells de dispositius mòbils les plataformes estan molt fragmentades. Aquestes dades inclouen (tauletes, smartphones...) i fan referència a tot l’espectre a nivell mundial.

2 Joc pioner del qual va aconseguir donar nom al gènere.

14 UnderNET

Figura 9: Gràfica d’utilització de sistemes operatius en dispositius mòbils

A nivell de dispositius de sobretaula observem a la figura 10, que les dades són molt més homogènies, on el sistema operatiu de Windows supera amb escreix a la resta en aquest perfil de dispositius. Fet que ens porta a considerar que la solució més adient per arribar al màxim de gent és aquella que contingui un percentatge més elevat ja que no disposem de dades absolutes. Així que considerarem que la opció que ofereix una major facilitat és un PC amb sistema operatiu Windows.

Figura 10: Gràfica d’utilització de sistemes operatius a nivell d’escriptori

Així doncs, resumint les decisions que es desenvolupen en els dos últims capítols, els requisits que es van especificar al principi del projecte són:

 Visualització en primera persona.  Món tridimensional.  Joc d’aventures amb components d’acció.  Jugabilitat per a entorns de PC (teclat i ratolí).

15 UnderNET

 Escalabilitat i modularitat: és un projecte que pot tenir continuïtat.  Aprofitar la xarxa (requisit marcat pel projecte UnderNET global).  Llengua anglès (requisit marcat pel projecte UnderNET global).

Conceptes teòrics a adquirir per el jugador Un altre punt important era definir quins coneixements teòrics es volien transmetre. Es va decidir que de cara aquesta fase en centraríem exclusivament en nivell de l’assignatura “Xarxes d’àrea local” / CCNA1. Conceptes que es pretenen que s’assoleixin:  PAN/LAN/MAN/WAN: Entendre la jerarquia de nivells de xarxa.

Figura 11: Jerarquia dexarxes

 ARP Request: Comprendre quina funcionalitat té aquest protocol.  Direccions IP i direccions MAC: Comprendre a què fan referència cadascuna. Tant a nivell de IPv4 com IPv6.  Màscares: Què són, què defineixen i la seva utilitat.  Ports: Què són, què defineixen i la seva utilitat.

4.2 GAME DESIGN DOCUMENT

El Game Design Document (GDD) és un document on es descriuen tots els aspectes del joc de forma detallada. Aquest document s’actualitza durant tot el cicle de desenvolupament per tal de reflectir els canvis que es van produint.

El contingut de la primera versió descriu la jugabilitat (gameplay), els personatges, història, aspectes tècnics i resta d’informació que es consideri necessària per començar la producció del joc.

En el cas d’aquest projecte és va considerar que els apartats fonamentals que havia de contenir eren:

16 UnderNET

 Introducció: Calia explicar d’on provenia la idea del projecte.  Descripció: Títol, perfil de públic al que anava dirigit, història del videojoc, així com també el seu guió.  Mecàniques del joc: regles del joc, mecàniques del joc i user interface (comandaments que faria ús el jugador)  Art Work: Moodboard, disseny dels escenaris i personatges, paletes de colors, GUI.  Àudio: Definició de tots els sons que es farien ús; on i perquè.

Durant el desenvolupament del projecte UnderNET, s’han generat dues versions de Game Design Document. La primera, com s’explicarà més endavant, va ser descartada per no complir amb els objectius inicials que s’havien proposat d’una manera clara. De totes formes moltes de les idees es van mantenir per a la segona versió.

4.3 GDD v1

En aquest apartat decriu el document Game Design Document – UnderNET (versió 1), però no es mostra la seva totalitat, doncs molts dels seus elements es veuen en la versió 2 del GDD. Acontinuació es fa un repàs sobre els seus trets més característics.

Aquesta primera versió del document (es pot trobar a l’Annex) va ser desenvolupada conjuntament pels també projectistes Alfredo Giraldós i Víctor Rodríguez. Es van assentar les bases del que seria el GDD final, malgrat l’estructura fianalment va variar.

En aquesta versió es va plantejar fer un joc modular i que funcionés a partir de paquets de minijocs, els quals anaven classificats per nivells o dificultats. L’estructura que es pretenia assolir era aquesta:

Figura 12: Comportament del joc UnderNET versió 1

17 UnderNET

El jugador es situava en un escenari genèric, pel que es podia desplaçar lliurement i en el que en funció de determinats events se li carregava un minijoc en concret. Aquest minijoc contenia un concepte que es volia que aprengués, l’elecció d’aquest venia donat per un valor aleatori. Els minijocs contenien diferents paquets de coneixements, fet que atorgava molta modularitat i escalabilitat pel futur. Al final de cada minijoc se’t premiava ja fos amb algun atribut/habilitat per l’escenari general o bé amb informació sobre la història; la finalitat era satisfer al jugador.

Com que els minijocs eren aleatoris es pretenia oferir una opció “Arcade” mitjançant la qual es podia escollir lliurement si es volia algun en concret.

Figura 13: Estructura de navegació de menús del joc

Els diversos minijocs estan definits al GDDv1 (veure annex).

El punt fort d’aquest primer disseny és que era modular, de tal forma que per estendre el joc només feia falta afegir nous minijocs. En contra, li faltava profunditat i, el que és més important, es salta l’objectiu d’oferir una alternativa que millori els jocs presentats en l’estat de l’art. No oferiem una interacció directe amb la xarxa amb la que el jugador estava conectat, i els diversos minijocs estaven focalitzats en conceptes molts específics i sense cap relació ni argumental ni pràctica els uns amb els altres.

També aquest factor aleatori en l’ordre d’aparició dels mini-jocs penalitza la estructura del joc, tot perdent control sobre ell. Això fa molt difícil aconseguir un bon balanç de joc. Tot i afegir el mode “Arcade”, això no soluciona el problema.

4.4 GDD v2

En aquest apartat es mostrarà la definició i contingut del Game Design Document – UnderNET (versió 2), que és una evolució i millora del primer.

18 UnderNET

Aquesta revisió del document, té en compte dos factors clau en la resolució del projecte.

 Arreglar les mancances de la versió des del punt de vista de disseny de jocs (aconseguir més profunditat de joc, integració real de la xarxa, conseqüència dins la línia argumental...).  Definir una estructura que permeti comunicar-se amb llibreries externes que captin dades reals de la xarxa on es troba situat el jugador. En la versió actual del joc, les dades sobre les xarxes són simulades, però es contempla que aquetes dades provinguin de fonts reals en el futur.

Per aquesta nova versió es va decidir generar una mena de beta o demo que permetés mostrar el camí cap on hauria d’evolucionar en següents projectes. A la vegada que es generava una estructura bàsica, d’on es pogués continuar. Sempre amb la idea que havia de ser escalable pel futur.

Aquesta nova estructura es basa en navegar pels diferents nivells de xarxa, que correspondran als diferents nivells del joc, per tant en un joc lineal. Els nivells de xarxa faran referència als esmentats l’aparat 4.2 Consideracions prèvies – Conceptes teòrics a adquirir.

Figura 14: Diagrama estructura del joc

A continuació es mostra la segona versió del document de disseny de joc completa:

GAME DESING DOCUMENT – UNEDERNET v2

TÍTOL El títol del joc és UnderNET.

19 UnderNET

LOGOTIP El logotip del joc pretén oferir dels conceptes xarxa i globalitat.

Figura 15: Logotip projecte UnderNET

AMBIENTACIÓ El joc està ambientat en un escenari del tipus futurista i ciència ficció, a l’estil de pel·lícules com Tron o Matrix.

Figura 16: Exemple d'estètica de Matrix

Figura 17: Exemple d'estètica de Tron

Es disposarà de diversos escenaris que permetin traspassar al jugadors diverses sensacions des de grans moviments mitjançant escenaris que semblen que no tinguin fi, o d’altres més

20 UnderNET

petits que donaran sensació més claustrofòbica. Dintre d’aquest escenaris es representaran de diverses maneres els diversos elements de la xarxa en funció e la nostra ubicació.

Els escenaris són dinàmics (no en aquesta versió, però ja es contempla en el disseny del joc), és a dir, en funció de al xarxa que ens situem seran d’una manera o altre.

GÈNERE I PÚBLIC OBJECTIU

GÈNERE És un joc educatiu, que contindrà matisos de joc d’aventures/plataformes i accions per donar-li caire més entretingut.

PÚBLIC OBJECTIU Està dirigit cap a un perfil eminentment universitari o amb estudis de grau superior, malgrat pot ser accessible per a tothom que tingui prou coneixements sobre la matèria. Ens trobem un públic que ha de superar els 16-18 anys que podria arribar fins els 50 anys. De totes maneres estaria recomanat per a un interval dels 18 a 35 anys.

HISTÒRIA DEL VIDEOJOC Ens trobem al paper d’un estudiant de la universitat de La Salle d’uns 20 anys d’edat, que ha sigut absorbit per la xarxa i entra al món virtual. El personatge estarà immers en aquest nou món perdut, i requerirà dels seus coneixements per poder-ne sortir. Durant el transcurs d’aquesta fugida visitarà els diversos mons que composen la xarxa: connexions, dispositius, etc..

TEXT NARRATIU El text narratiu que es pot llegir a continuació és el detonant d’un fil argumental, que de cara aquesta versió no es veurà reflectit dins el joc. Tot i això, era important definir una història ja més acurada perquè en la resolució de la línia argumental tingués la màxima coherència possible.

“Era la típica setmana, fins a dalt de pràctiques, sense temps per estudiar i ja no parlem de relacions socials fora la universitat...

L’ordinador marcava les 21:17, vaig esbufegar una mica i remoure sobre la cadira, vaig mirar al voltant i no hi havia ningú a la sala. Em trobava a la planta -2, als laboratoris de telemàtica, aquells que a La Salle Barcelona els agradada tant presumir de CISCO NetAcad, si heu estat per allà crec que sabreu a quins em refereixo. Però tornant a la meva història; sol, acabant la pràctica que havia d’entregar en el transcurs de les pròximes 48h, quan va esdevenir una baixada de tensió, els llums van pampallugar, i les plaques dels ordinadors van emetre un xiulet. Vaig córrer a salvar les evolucions de la pràctica, amb la intenció de no perdre la feina feta, però era massa tard...

21 UnderNET

L’ordinador s’havia bloquejat, i per moltes tecles que premés i l’increpés, continuava sense respondre. Em vaig maleir a mi mateix per no ser curós i fer còpies de seguretat, i va ser en aquell precís instant que la pantalla va començar a brillar d’una manera estranya, la interfície va començar a canviar, convertint-se tota en la pantalla d’una consola.

A la consola van començar a aparèixer missatges amb textos d’ajuda. Estranyat vaig recórrer la sala cercant algú que m’estigués bromejant, però ningú. La pantalla continuava mostrant cada vegada més missatges dient el mateix. Em vaig aixecar i dirigir al final de la sala on estan situats tots els racks amb la intenció de desconnectar el meu terminal de la xarxa, i que ningú fes res remotament. Mentre caminava ja notava que quelcom no encaixava, però ho vaig relacionar al cansament. Un cop vaig arribar, vaig buscar el cable que corresponia a la meva fila mentre el neguit creixia. El vaig localitzar, i tocar...”

GUIÓ DEL VIDEOJOC Som un estudiant que ha sigut absorvit per la xarxa, a la que haurà d’ajudar a resoldre una sèrie de conflictes per poder sortir-ne.

En aquesta demo ens trobarem, amb que se’ns ha assignat la tasca del transport d’un paquet que permeti la desinfecció d’un dels dispositius. Per poder-ho fer haurem de viatjar a través de tota la xarxa, sortint del dispositiu en el que ens trobem, travessant la nostra xarxa (LAN), Internet (WAN) i arribant finalment al dispositiu al qual li haurem de fer arribar el paquet en condicions.

Durant aquest viatge caldrà utilitzar diversos coneixements de la teoria de telemàtica, per poder continuar.

MECÀNIQUES DE JOC Aquí repassem i definim els diversos nivells pels que haurà de passar el jugador per poder dur a terme la seva missió. La missió es composarà de tres pantalles o escenaris, que representaran diversos estats de la xarxa.

MAZE: NIVELL 1 En aquest primer nivell el personatge es troba en una xarxa local (LAN). Ha de recórrer un laberint que el portarà fins una habitació central, on es trobarà un router que li permetrà saltar a una xarxa superior (MAN/WAN).

Durant el transcurs del recorregut trobarà cubs que representaran els diversos elements que també composen la xarxa. En un principi apareixeran com a desconeguts (mitjançant una textura en forma d’interrogant). Per conèixer quin tipus de dispositiu és així com tota la seva informació (direccions IP i MAC), el jugador mitjançant la interacció del teclat generarà una simulació de comanda “ARP request”. Un cop executada se li mostrarà tota la informació i el cub passarà a tenir l’aspecte “real”. Aquesta informació es representarà en forma de text per la pantalla i amb la textura del tipus de dispositiu.

22 UnderNET

Idealment es volia tenir classificació per: router, PC, dispositiu mòbil i impressora. En diàlegs amb el projectista es va considerar que no era viable fer aquesta distinció.

És important aquesta interacció i cerca, ja que serà el motiu gràcies al qual el router s’habilitarà per permetre-li passar al següent nivell.

Resumint tindrà dos objectius marcats:

 Investigar els elements de la xarxa  Resoldre el laberint per poder sortir.

Donada l’alta dificultat de resoldre el laberint des d’una primera persona, es plantejaven dues vies d’ajuda al jugador per poder assolir una corba de de dificultat adequada. Aquestes es descriuen a continuació.

 Elements identificatius: Afegir elements característics que indiquin punts del laberint

 Minimapa: El jugador disposarà d’una vista zenital des de la qual podrà saber en tot moment en quina ubicació es troba i quina és la forma del laberint. No pretén indicar on es troben els dispositius, és un repte que encara cal fer-l’ho pel seu compte. La utilització de dels elements identificatius oferia una conjunt d’inconvenients: la dificultat continua sent elevada (encara pot ser frustrant), els elements poden confondre’s respecte els dispositius que es pretenen cercar i que es vol oferir un marc homogeni, una mateixa xarxa per la qual es trasllada netament i que únicament conté els dispositius de la xarxa. D’altra banda ofereix un repte major, el que pot suposar un al·licient per determinades persones que els agradi quanta més dificultat millor.

Finalment l’opció escollida va ser el minimapa descartant la primera ja que el nostre objectiu és obtenir el major nombre de jugadors interessats en el joc. Massa dificultat pel que correspondria a un primer nivell.

A continuació es mostra una llista d’elements presents en aquest últim nivell:

. Cubs desconeguts: textura interrogant . Cubs descoberts: textures dels diversos dispositius . Personatge: representat dos braços.

CITY: NIVELL 2 En aquest nivell l’usuari es trobarà en un escenari molt extens, que indicarà que es troba en un nivell superior, és a dir, s‘haurà traslladat a una xarxa superior (ex: de LAN a MAN). Aquí

23 UnderNET

disposarà de la direcció IP destí a la qual ha d’anar per entregar el paquet, el jugador haurà de cercar a l’escenari a quina xarxa correspon aquesta direcció.

Les diverses xarxes estaran representades en forma de torres que composaran l’escenari.

Unes torres serviran per pujar a una xarxa superior o bé una inferior (de cara aquesta versió no està implementat) i en conseqüència les dimensions dels escenaris variaran.

Un cop s’ubiqui al costat de la torre, se li mostrarà la direcció de la xarxa i la mascarà que l’acompanya, amb aquesta informació ha de ser capaç de conèixer si la direcció destí hi és dins.

Durant la mostra de la informació l’usuari podrà validar si aquesta xarxa es correspon amb la que busquem. En cas afirmatiu passarem al nivell 3, en cas que ens equivoquem és dispararà la seguretat del nivell. Això implica que sortiran 3 enemics que tindran la finalitat de col·lisionar amb el jugador.

Es disposen de 3 vides (o impactes) per assolir l’objectiu; en cas que passés això, és a dir, impactessin els enemics 3 cops, s’acaba la partida i cal començar el joc de nou.

D’altra banda es disposarà d’una arma per defensar-se en cas que fos necessari, que permetrà eliminar-los.

A continuació es mostra una llista d’elements presents en aquest últim nivell:

. Torre principal: gran estructura rodejada per altres elements, té la funció de traslladar a una xarxa superior. . Torres: representada en diferents models i textures, permeten accedir a nivells inferiors/dispositiu. . Enemics: personatges que atacaran al jugador. . Personatge: representat per dos braços, més l’arma que permetrà defensar-se.

DEVICE: NIVELL 3 Aquest nivell succeeix al destí final: el dispositiu. Però falta un últim pas, saber a través de quin port cal entregar la informació.

Ens trobarem un conjunt de plataformes que es mouran per un escenari quadrat i tancat que simula el nostre dispositiu final. Com ja succeïa en el nivell 2, se li donarà al jugador una informació amb la qual haurà de cercar per l’escenari. Coneixerà el nom del protocol al qual pertany el paquet, i haurà de trobar el port/interfície. Al ubicar-se al costat de l’element (port) li apareixerà el número al qual fa referència. Tindrà la possibilitat de validar-ho:

24 UnderNET

 En cas que s’equivoqui, se li restarà una vida i se li mostrarà a quin protocol fa referència realment.  Si encerta es finalitza el joc. L’escenari emfatitzarà el món tridimensional en el qual es troba, ja que l’usuari s’haurà de traslladar també en l’eix d’alçada. En aquest cas els enemics aniran perseguint el jugador ininterrompudament en formada d’onades. Aquestes onades implicaran aparicions d’un nombre determinat d’enemics per tot l’escenari en ubicacions aleatòries. En aquest nivell apareixeran enemic encara que no es cometi cap error, afegint-hi més dinamisme. Es seguirà comptant amb una arma per defensar-se dels enemics, com ja succeïa al nivell 2.

Es tracta d’una pantalla més d’acció i plataformes que les altres, ja que es troba en un nivell final, en el qual el nivell de dificultat ha de créixer. Se suposa que l’usuari ja domina les mecàniques de joc dels nivells anteriors i per tant requereix de mecàniques més complexes. D’aquesta forma pretenem assolir un equilibri adequat entre el repte i l’habilitat del jugador

A continuació es mostra una llista d’elements presents en aquest últim nivell:

. Plataformes mòbils: permetran el desplaçament tridimensional per accedir a ubicacions de determinats cubs. . Cubs: representaran els diversos ports als quals s’hi ha d’accedir. . Enemics: personatges que atacaran al jugador. . Personatge: representat per dos braços, més l’arma que li permetrà defensar-se.

USER INTERFACE Els comandaments escollits per al joc són el teclat i el ratolí, ja que són els dispositius d’entrada més utilitzats en la plataforma PC. La relació acció-tecla ve donada per l’ús habitual en altres jocs del mateix gènere, així atorguem certa familiaritat al comportament que l’usuari espera. A continuació es mostren dues taules amb la relació de comandes de joc amb tecles.

Moviments Tecles Interaccions Ratolí Davant W Moviment Càmera Moviment vista Esquerra A Disparar Botó principal Darrera S - Botó secundari Dreta D Salt SPACE

Acció E ESC PAUSA

25 UnderNET

ARTWORK Aquest apartat s’explica en profunditat en l’apartat de Creació de l’art (capítol 4).

ÀUDIO En aquest apartat s’identifiquen els diversos sons bàsics que caldrà integrar dins del joc, sense entrar en detall, ja que s’escapa de l’abast d’aquest projecte.

 Cançons: Menú i nivells del joc.  Efectes: . Aparicions de GUIs. . Animacions personatge: passes, trets, impactes. . Animacions enemics. . Ambientació escenaris. . Victoria i derrota.

26 UnderNET

5. CREACIÓ DE L’ART

En aquest apartat s’inclou els dissenys plantejats previament al desenvolupament (GDDv2, capítol 3 Disseny del joc) en el procés.

5.1 INSPIRACIÓ

Tron i Tron Legacy Clarament la principal influència ha vingut donada per la pel·lícula Tron [10] y la seva versió més moderna Tron Legacy [11]. Ja que aquest ja havia pretès mostrar una visió fictícia del que seria l’interior d’una màquina.

Figura 18: Exemple ciutat Tron

Figura 19: Exemple ciutat Tron Legacy

També van aparèixer altres influències com la trilogia Matrix [12] o la sèrie televisiva Reboot [13]

27 UnderNET

Figura 20: Exemple estètica Matrix

Figura 21: Frame sèrie televisiva ReBoot

El món del cinema no és l’únic que va influir en l’estètica del joc. Els videojocs actuals també van oferir un ventall d’idees.

Portal Portal [14] és un videojoc desenvolupat per la companyia Valve Studios. El joc consisteix en una aventura en primera persona on el jugador pot traslladar-se i veure diversos escenaris 3D mitjançant la creació de portals que comuniquin entre ells. L’estètica neta i simplista ha influït molt directament, en la manera de com dissenyar els escenaris. Així com també la idea de navegació i interconnexió de mons.

Figura 22: Fotograma del videojoc Portal

Cal destacar que alguns dels models utilitzats en aquest projecte han sigut modificacions dels models generats a semblança de personatges el joc.

28 UnderNET

5.2 ART WORK

L’art work fa referència a tota aquella feina visual que serà utilitzada en el procés del joc, ja sigui en d’imatges 2D, models tridimensionals, etc.

MOODBOARD El moodboard és un collage d’idees que mostren cap a quina direcció es vol dirigir l’estètica del producte final. Aquest és el desenvolupat des d’un inici (ja que no s’ha volgut escapar d’ella).

Figura 23: Moodboard

PALETA DE COLORS S’han designat dues paletes de colors, tot i que una és la principal. La raó per la qual s’han realitzat dues, és perquè al tenir tres escenaris, es pretenia certa heterogeneïtat per donar sensacions diferents.

Disposem de la primera paleta o principal, que és la que s’utilitza per a la interfície, menú- Com s’observa són colors més aviat càlids ja que s’utilitzaran per escenaris tancats.

Figura 24: Paleta de colors principal

29 UnderNET

La segona pretenia colors més freds per donar sensació de solitud, per a l’amplitud, clar exemple l’escenari dos (City).

Figura 25: Paleta de colors secundaria

Aquestes paletes al final no has sigut estrictes, han servit de manera orientativa, ja que al final alguns colors que apareixen al joc, no hi són a la paleta.

Un dels motius que es contingui diversos tocs d’altres colors es deu a que es va anar amb molt en compte amb l’elecció; de no abusar del blau i especialment del verd, ja que es relacionen automàticament amb altres productes, com per exemple el verd amb Matrix o blau amb Tron. Aquesta semblança es devia a que com en els casos esmentats utilitzàvem colors molts saturats, perquè donar l’aspecte d’artificial.

GUI S’han escollit de font la Courier New, ja que es sol relacionar amb el codi font de programes informàtics.

Per als dissenys de GUIs de comunicació ha sigut OCR A Std.

30 UnderNET

5.3 DISSENYS FINALS

Aquí es mostren els diversos dissenys i el resultat obtingut d’ells; tant pel que fa a gràfics 2D com als models tridimensionals. La majoria d’aquest dissenys estan aplicats a UnderNET, encara que n’hi ha que no s’han afegit, perquè en la implementació final es va considerar que no calien. Tot i això, es mantenen dintre del document (i com a possibles assets3) per a futures millores i implementacions.

Els diversos components generats són la suma de dissenys completament nous desenvolupats exclusivament per l’aplicació, i també elements realitzats per tercers que es podien aprofitar, ja fos integrant-los de manera directa o bé modificant-los per afavorir-ne l’encaix.

GUIs Els GUI (Graphic User Interface), és la interfície gràfica que permet la interacció de l’usuari amb l’aplicació (joc en aquest cas). En el cas d’UnderNET, farà referència aquells components gràfics que es superposaran a la pantalla de joc (càmera 3D).

Per al disseny dels components 2D, s’ha utilitzat l’eina Adobe Photoshop, concretament en la versió del paquet CS6. Totes les imatges han sigut exportades en dos formats PNG en el cas de que calguessin transparències i JPEG si no els hi calia, amb l’objectiu de reduir el pes de les imatges.

Per afavorir la lectura i una major integració dins el joc, s’ha dissenyat 3 components que faciliten el diàleg, entre el videojoc i el jugador. Son components que es situaran darrera del text proporcionant la sensació que són consoles de diàleg. Com s’observarà, s’ha buscat l’estètica futurista, fins i tot un punt decadent, que permetés simular el diàleg.

El primer disseny s’utilitzarà per a texts llargs i “estàtics”, informació del jugador ja sigui vida o destí, etc. Pensat perquè es situï, a la part dreta de la pantalla.

Figura 26: Consola de diàleg dreta

El segon serveix pels diàlegs d’interacció amb l’escenari, ubicada també a la part superior però a l’extrem esquerra.

3 Anglicisme utilitzat per fer referència a eines o recursos útils en una aplicació.

31 UnderNET

Figura 27: Consola de diàleg Esquerra

Un altre disseny que va caler crear va ser la imatge del cursor, que serviria per senyalitzar la ubicació del personatge dins el minimapa del nivel 1 (maze). Es va realitzar, partint dels patrons aplicats als altres GUIs, un aspecte més metàl·lic. També se li va afegir un aura al voltant que ajudes a identificar-lo respecte la resta del mapa.

Figura 28: Marcador del minimapa

Altres GUIs que van caler van ser els de comunicació puntual i crítica per l’usuari. Es tracta de GUIs que ocuparan la totalitat de la pantalla temporalment per informar-lo d’un succés (impacte o nova onada d’enemics). Per aquest motiu tenen la mateixa resolució que la pantalla de joc (1024x768).

Figura 29: GUI d'impacte

Figura 30: GUI de nova onada d'enemics

32 UnderNET

Figura 31: GUI enemics apropant-se

Partint de la resolució de 1024x768, es van generar els botons dels diversos menús i navegació del joc.

Figura 32: GUI dels botons de navegació

MODELATGES 3D Els elements tridimensionals s’han generat a partir del programa Autodesk 3D Studio Max, en la seva versió 2012 per a estudiants.

Es poden classificar en dos grans blocs, que són els escenaris i personatges més assets.

Escenaris Els escenaris s’han dividit en funció dels nivells: maze, city i device.

Maze

En el primer cas ens trobem el laberint (maze), com es comentarà amb detall al apartat d’implementació, finalment es va decantar per generar un escenari estàtic per aquest projecte, fet que va produir que s’hagués de dissenyar manualment. Aquest laberint, està dissenyat amb l’objectiu d’arribar a una sala central, sortint d’una de les arestes exteriors del laberint. El laberint primer es va dissenyar sobre paper per posteriorment, generar-lo tridimensionalment. Cal matisar que després d’algunes proves a nivell de testeig, s’ha anat modificat per facilitar el seu recorregut.

33 UnderNET

Figura 33: Desenvolupament laberint amb 3D Studio Max

City

En aquest escenari va caldre generar els diversos elements que composarien la ciutat, és a dir, els edificis. Com que es volia generar una sensació amplitud, es van dissenyar amb la idea que el jugador els veuria com a gratacels. Per donar homogeneïtat, tots els edificis es van dissenyar amb el mateix patró d’estètica (esmentats anteriorment), malgrat això es pot observar que els edificis varien respecte las primeres versions que es poden veure al GDDv1. Això es deu que va aparèixer una nova branca d’influència; va ser l’electrònica. Tots els edificis estan pensats per simular diversos components d’un circuit elèctric, així s’aconseguia un patró que conferia unitat estètica. Primer tenim els edificis generals que serveixen d’interconnexió a xarxes més petites, on haurem de comprovar les màscares durant el joc. Són edificis més neutres sense cap edifici destaqui per sobre dels altres.

Figura 34: Vista frontal edificis pantalla City

34 UnderNET

Figura 36: Vista lateral edificis pantalla City

Un altre component, que es va dissenyar va ser una plataforma que permetés interactuar situant-se per sobre d’ella.

Figura 35: Vista zenital de la plataforma

Finalment ens trobem amb l’element sobre el qual s’estructura tota la ciutat: la torre. La torre té dues funcionalitats bàsiques l’accés a una xarxa superior i la d’utilitzar-se com a referència. Això últim és important quan el jugador es desplaçarà per grans superfícies i rodejat per elements similars. És per aquest motiu pel qual es va dissenyar perquè tingués un aspecte més majestuós i destaqués per sobre dels altres.

35 UnderNET

Figura 37: Vista lateral de la torre central de la City

Figura 38: Perspectiva de la torre central de la City

Device En aquest escenari només va caldre dissenyar les diverses plataformes mòbils. Donat que se li va voler oferir, uns complements com eres en forats, no es podia generar a través de Unity, com s’havia fet amb altres elements més bàsics, pel que es van modelar i exportar amb el 3D MAX.

Figura 39: Plataforma mòbil escenari Device

36 UnderNET

Personatges i assets Finalment només va caldre crear dos personatges: l’enemic i els diversos elements que composen el personatge principal, tenint en compte que el joc utilitza una vista en primera persona.

Personatge principal El personatge principal es composa de dos elements, els braços i l’arma (que apareixia només a les pantalles de city i device). Els braços van ser reaprofitats d’una pràctica realitzada per mi en l’assignatura Animació Avançada de la carrera.

Figura 40: Braços personatge

Mentre que l’arma va ser adaptada d’un model 3D lliure [15] de descarregat de la pàgina web Turbosquid4 .

Figura 41: Model arma personatge

4 http://www.turbosquid.com

37 UnderNET

Enemic L’enemic és una adaptació pròpia basada en els models del joc Portal [14], l’estructura bàsica està extreta del model lliure descarregat “Portal turret” [16]. Es fonamenta en un robot (mantenim estètica futurista), pensat perquè levités i el seu desplaçament fos aeri.

Figura 42: Model enemic

Assets La majoria d’assets s’han generat, directament amb el motor gràfic de Unity, menys un cub extret del web Turbosquid ja que es va considerar que esqueia millor que els assets generats anteriorment. Es tracta d’un cub [17] fonamentat en el videojoc un altre cop de Portal, que s’aplicarà a la pantalla device quan es busquin els ports.

Figura 43: Model cube device

38 UnderNET

TEXTURES Les textures són un l’altre element bàsic en dintre del disseny del joc, ja que son qui acaban donant l’aspecte final que a tots els elements anterior. En el cas d’UnderNET, tindrem una combinació entre textures realizades per al projecte, juntament amb materials propis de Unity. Això fa que en aquest apartat no es vegi totes aquelles textures que apareixeran en el joc.

En moltes situacions les textures/materials que s’aplicaven als elements de l’escena requerien color plans, pel que únicament amb material difusos pròpis de Unity ja podiem texturitzar-los. Aquest mètode de texturització permetia optimitzar el joc ja que el fet de no tenir imatges com a textures reduïa el pes i agilitzava els càlculs.

 Textures basades pels cubs pel nivell maze.

Figura 44: Textures cubs pantalla maze

 Textures complementaries per diveros escenaris, que permetien texturitzar parets i elements simples de l’escena.

Figura 45: Textures complementaries escenaris

39 UnderNET

 Textures basades en el metall.

Figura 46: Textures basades en el metall per a escenaris i components

 Textures comodí, aquelles que no tenien una presencia destacada però calia texturitzar, com per exemple els braços.

Figura 47: Textures comodí

40 UnderNET

6. IMPLEMENTACIÓ

En aquest apartat s’explicarà com s’ha desenvolupat tot l’apartat tècnic del projecte.

6.1 DEFINICIÓ TECNOLOGIA

Coneixent que el nostre dispositiu sobre el que s’executaria el joc seria un PC, i ens mouriem en un entorn tridimensional, calia prendre la desició de quin motor gràfic s’escolliria pel desenvolupament. Després d’una primera cerca es van escollir tres candidats a motor gràfic, els quals es descriuen a continuació.

COMPARATIVA MOTORS GRÀFICS

UNREAL ENGINE 3 Unreal Engine és un motor de joc desenvolupat per la companyia americana de videojocs Epic Games. La primera versió va ser presentada l’any 1997 i s’han succeït 3 versions més fins arribar la que ens pertoca: Unreal Engine 3.

Aquesta tercera generació va ser presentada l’any 2007 dissenyada amb les versions:

 DirectX 9/11: Windows i Xbox 360.  OpenGL: PlayStation 3, Mac OS X, iOS i Android.  Stage 3D: Adobe Flash Player 11, PSVita, Wii U.

Gràfics

Destaca per les diverses tècniques avançades de renderitzat:  Suport multi-thread per a diversos nuclis.  Il·luminació avançada: . HDRL (High Dynamic Range Lighting): Sistema de renderitzat de llums amb rang dinàmic, que permet la representació de diverses intensitats de llum. . Il·luminació per píxel: Sistema en que es calcula la llum píxel per píxel en una imatge renderitzada (per-pixel lighting). . Ombres dinàmiques.

41 UnderNET

Figura 48: Demostració motor gràfic Unreal Engine 3

Física

 PhysX: Desenvolupat per Nvidia és una capa de software entremig (“middleware”) que habitualment s’executa en la targeta gràfica (tot i que no totes ho permeten) que té la funcionalitat de desenvolupar càlculs físics complexes, alliberant els motors gràfics del seu desenvolupament.

Animacions

 FaceFX: programa que permet la bona sincronització entre l’animació de la parla i l’àudio.

UDK

 Unreal Development Kit, conté les diverses eines pel seu desenvolupament. El seu ús és gratuït sense usos comercials.

Llicències

 Proporciona a gratuïta per alumnes/usuaris sense beneficis econòmics.  Una llicència de 99$, i en el cas que el desenvolupador superi els 5000$ en guanys Epic Games es queda el 25% dels beneficis.

CRYENGINE 3 CryEngine 3 és un motor de jocs desenvolupat per la companyia alemanya Crytek. Com succeïa amb el motor Unreal, aquesta és la tercera versió presentada l’any 2009 (v1-2006, v2-2007). Els motors CryEngine s’han caracteritzat pel seu gran grau de realisme i per requerir de les tecnologies més noves. De fet la primera versió va ser desenvolupada com a motor de demostració per a l’empresa Nvidia.

42 UnderNET

Figura 49: Evolució del motor CryEngine Aquesta generació està dissenyada per les plataformes:

 Microsoft Windows (DirectX 9/11 per plataformes PC).  Xbox 360, PlayStation 3, Wii U.

Gràfics

 Suport multi-thread per a diversos nuclis.  Sistema de pintat HDR (High Dynamic Range).  Il·luminació global dinàmica en temps real (Real-time Dynamic Global Illumination) a nivell de píxel (per-pixel lighting).  Deferrer rendering: Pintat que permet l’ús simultani d’un gran nombre de llums.  Generació d’ombres: ombres toves (soft shadows), normal mapping, oclusió ambient en espai de pantalla (Screen Space Ambient Occlusion), etc.  Simulació de l’efecte d’adaptació dels ulls als canvis bruscos en la intensitat de la llum.

SDK Ofereix un editor gratuït anomenat CryEngine 3 Free SDK; és un editor d’escenaris dissenyat per l’edició de nivells per a jocs desenvolupats amb aquest motor gràfic. La finalitat d’aquestes eines per facilitar la programació, animació i creació d’objectes.

43 UnderNET

Figura 50: Demostració del motor CryEngine 3 També ofereix la possibilitat d’aprofitar aquest editor per incloure’l dins de jocs (per exemple FarCry i Crysis) per oferir-se en forma de sandbox5, permeten customitzacions i creacions de nous escenaris.

Llicències

 CryENGINE® Free Use: proporciona a gratuïta per alumnes/usuaris sense beneficis econòmics.  CryENGINE® 3 Independent Developers Platform: permet la lliure distribució comercial a canvi d’un 20% dels beneficis obtinguts.  CryENGINE® 3 for Independent Studios, Free To Play Games or Downloadable Games: cal posar-se en contacte amb la companyia.

UNITY 4 Unity 4 és un motor de jocs multiplataforma amb una IDE6 (Integrated Development Environment) pròpia per la companyia Unity Technologies. Originariament va aparèixer l’any 2005 com un entorn pel desenvolupament per a dispositius Mac (presentat a la Apple’s Worldwide Developers Conference 2005). Des de llavors i gràcies a l’èxit que van començar a assolir van continuar expandint-se cap altres plataformes i millorant les seves característiques.

La versió Unity 3 (2010) ja oferia moltes de les eines disponibles en motors en teoria força superiors, complementant-la posteriorment amb Unity 3.5 que atorgava caraterítiques encara més potents com renderitzat en HDR, renderitzat multi-threaded, sistemes de pathfinding, sistemes de partícules Shuriken...

5 Mode de joc on es poden commutar algunes de les característiques del joc, oferint una altra perspectiva al joc 6 Eina informàtica que ofereix al programador un entorn més còmode pel desenvolupament

44 UnderNET

L’any 2012 apareix la versió Unity 4, que és la que s’ha analitzat.

 DirectX 11: Windows i Xbox 360  OpenGL: PlayStation 3, Mac OS X, iOS i Android  Wii APIs  També per Windows Phone 8, Windows 8, Xbox One i PlayStation 4.  Suport Web mitjançant un plugin (navegador).

Gràfics

 Bump mapping: tècnica per assignar rugositat a la textura dels objectes.  Reflection mapping: tècnica per simular la reflectància d’un material.  Parallax mapping: tècnica de millora del bump mapping.  Screen Space Ambient Occlusion (SSAO): tècnica per simular la reflectància de la llum en material no-reflectant. Desenvolupat per Crytek.  Ombre dinàmiques.  Efectes de post-procés.  Partícules Shuriken: sistema de partícules propi de Unity.

Figura 51: Demostració del motor Unity 4

Física

 PhysX (explicat prèviament motor Unreal Engine 3).

Scripting El scripting està basat sobre una implementació de .NET anomenada Mono. Mono és un conjunt d’eines open source (programari lliure), que ofereix un compilador multi llenguatge com a característica més remarcable. És important ja que ofereix finalment a Unity la possibilitat de programar en diversos llenguatges.

45 UnderNET

. C# . UnityScript: una versió de Javascript, potenciada amb atributs de Unity . Boo: un tipus de llenguatge amb jerarquia i comportament com Phyton

Llicències

 Proporciona a gratuïta per alumnes/usuaris sense beneficis econòmics. Algunes propietats i característiques no estan disponibles per aquesta versió.  Unity Pro és la versió completa del motor gràfic amb tot habilitat en a la IDE. Es pot adquirir per un preu de 1500$.  Conté una amplia tenda de scripting i plugins, la qual permet ampliar la IDE.

ELECCIÓ MOTOR GRÀFIC Després d’analitzar les tres alternatives que s’oferien es tria l’opció de Unity, per un conjunt de decisions i facilitats. Els motius que decanten per aquesta tecnologia són:  Es disposa d’una versió gratuïta per poder desenvolupar-la (també en les altres versions).  Arquitectura .NET, fet que permet una interconnexió amb llibreries .dll7. La importància d’aquest fet radica en la modularitat del projecte, permet un desenvolupament paral·lel de la llibreria de telemàtica, que ens donarà les dades necessàries.  Potser el motor gràficament menys eficient, però el joc no conté models tridimensionals amb molts polígons i per tant aquesta característica no es requeria.  Acceptació i bona integració d’elements importats per eines com 3D Studio Max, Maya, Blender, Adobe Photoshop.  Bona importació i integració de l’àudio (projecte paral·lel mòdul d’àudio).  Corba d’aprenentatge inferior als altres motors gràfics.  Fàcil exportació multiplataforma.

7 Dynamic Link Library: fitxer de llenguatge executable pel sistema operatiu Windows

46 UnderNET

6.2 ENTORN DE DESENVOLUPAMENT

IDE UNITY L’entorn de desenvolupament de Unity es tracta d’un editor bàsic d’escenaris i de projectes. És a dir, s’encarrega de la creació i edició d’escenaris i components, com també gestió de la solució global que composen els diversos. Això implica que el desenolupament del codi no es gestiona a la mateixa IDE. A més a més, es recorda que parlem de l’edició gratuïta pel que algunes caracterítiques estan deshabilitades.

Pel desenvolupament del codi (scripts), Unity proporciona un programes auxiliar que permeten la creació i edició d’aquests scripts, anomenat MonoDevelop. Aquest programa permet gestionar en tots aquells llenguatges de Mono (explicat anteriorment) així com també ajuda contextual. De totes maneres, s’ha escollit un altre editor, ja que Unity permet l’elecció: Microsoft Visual Studio 2012. S’escull aquell editor ja que és un entorn més cómode pel desenvolupador ja que està més familiaritzat amb ell.

La composició de panells a la IDE és personalitzable, però per aquest projecte s’ha escollit aquesta composició:

Figura 52: IDE de Unity

Es pot observar que està distribuides en tres sectors: el central on hi ha un visualitzador, a la part inferior i a la dreta. Fixant-se en els sectors es poden distingir els diversos panells que composen la IDE, ja siqui en forma de pestanya o perquè comparteixen espai.

47 UnderNET

Central

 Scene: Aquí és on es visulitza i ubiquen els diveros elements per a la gestió de l’escena.  Game: Visualitzador per poder executar en temps real, l’escena. És el banc de proves.

Inferior

 Project: Conté la jerarquia de totes les carpetes i els seus detalls del projecte. El nostre explorador d’arxius o finder.  Consola: Mostra els errors, advertencies i diàlegs del joc

Dreta

 Hierachy: Conté i gestiona tots aquells elements que es troben a l’escena.  Inspector: Conté els detalls de l’elements seleccionat del Hierachy, atributs, components8...

MICROSOFT VISUAL STUDIO 2012 Aquest ha sigut l’editor seleccionat per l’apartat de programació. L’elecció ha vingut donada exclusivament perquè ja existia una experiència prèvia amb aquest programa.

El programa permet treballar simultaneament amb diversos fitxers i gestionar-los mitjançant el Solution Explorer (dreta). També oferia la possibilitat de treballar amb un repositori, però per les caracterítiques del projecte no ha calgut.

Figura 53: Entorn Microsoft Visual Studio 2012

8 Els scripts i controladors es consideren components de l’objecte

48 UnderNET

6.3 GESTIÓ DEL PROJECTE AMB UNITY

El mètode de treball en Unity és mitjançant escenes, cada nova escena implica una nova pantalla de joc. En aquest projecte ens escau força bé ja que implica la creació de quatre escenes principal, una per a cada nivell més pel menú principal.

Dins d’aquesta escena s’hi ubiquen els diversos elements que la composaran, anomenats objectes. Això es pot realitzar mitjançant la IDE, la qual permet arrossegar els objectes dins l’escena o bé a través de codi (code behind). La gestió pot realitzar-se mitjançant la IDE (Hireachy + Inspector) o per un altre codi.

Scripts El codi o lògica del joc es defineix a través d’arxius anomenats scripts, que es poden escriure amb els diversos llenguatges de Mono (C#, Javascript, Boo), en el nostre cas Javascript, principalment per motius de comoditat. Aquest scripts es comporten com a components d’un objecte de l’escena, fet que organitza el codi en funció dels elements de l’escena als que afecten. També produeix que tinguem dues vies per afegir tots aquells scripts que són més genèrics, ja que podem afegir-los a objectes buits a l’escena o el mètode escollit en el nostre cas assignar-los al personatge principal. Remarcar que un mateix objecte pot contenir varis scripts i que gràcies a l’ús d’aquest mètode és molt simple la reutilització per a altres escenes.

Unity ofereix un parell de característiques interessants en la utilització d’aquest scripts.

 La primera és que tots disposen de dues funcions genèriques Start() i Update(). Start ens ofereix executar el contingut en el moment que s’inicialitza l’escena i Update executa a cada iteració del joc.  Les variables genèriques o atributs dels scripts es poden accedir a través del Inspector del IDE, de cara a poder canviar els valor fàcilment. És força útil pel moment de ajustar les variables per a la jugabilitat.

Jerarquia del projecte La IDE de Unity és qui s’encarrega de gestionar el nucli de l’aplicació, i ens proporciona una carpeta anomenada Assets on afegir i modificar tot el contingut que pertany a les escenes.

La jerarquia o distribució de carpetes que s’ha utilitzat és aquesta:

 AstarPathFinderEditor: Llibreria externa que permet la gestió de pathfinding. S’ha treballat amb ella malgrat al final no s’aplica per aquesta versió (explicat a l’apartat Tecnologies no aplicades)  Control Setups: Carpeta autogenerada per Unity al crear el projecte que conté aquells paquets d’assets predefinits escollits. En el cas d’UnderNET només s’ha

49 UnderNET

agafat la carpeta Standar Assets que conté Character Controller, Skybox, Physic Materials, Terrain Assets.  Editor: Carpeta auxiliar per la llibreria AstarPathFinding.  Extra GUI Skins: Carpeta que conté nous estils per al botons i elements GUI.  Materials: Aquí és on estan tots els materials i textures utilitzats al projecte.  myFBX: On es troben tots els objectes 3D generats pel 3D Studio Max.  navMesh: Llibreries complementaria externa, per a la gestió dels objectes 3D.  Plugins: Carpeta gestió de llibreria AstarPathFinding.  Prefabs: On emmagatzemem els objectes prefabs (explicat a Desenvolupament de nivells)  Resources: Conté les fonts de tipografia.  Scenes: On es guarden les diverses escenes que composen el joc  Scripts: Aquí és on s’ordenen els scripts de codi. Tenen una subdivisió en funció del seu ús: Generic (s’utilitzen en diverses escenes), phase1, phase2, phase3 (scripts propis de cada nivell) i Menu (referents a animacions i redireccions de botons).  Terrain: on es troben els terrenys de cada escena  UnityUtils: Carpeta que proporciona components extra.

Figura 54: Arbre de carpetes de la carpeta Assets

50 UnderNET

6.4 DESENVOLUPAMENT DE NIVELLS

El desenvolupament de nivells es va realitzar seguint l’orde en que aquests apareixen al joc. El primer nivell va ser el que va necessitar de més temps de desenvolupament ja que va implicar el desenvolupament d’algunes eines i scripts que s’aprofitarien posteriorment.

MAZE: NIVELL 1 Com ja s’ha explicat en les mecàniques del joc (apartat Disseny del joc), aquell nivell es composava en el recorregut d’un laberint, amb la cerca de diversos elements que estaven situats per la pantalla.

El primer pas va ser la creació d’un terreny sobre el qual es pogués treballar, en el cas d’aquest nivell n’hi havia prou amb un únic pla que fés de terra sobre el que afegir els models. Després calia ubicar els objectes dins de l’escena, això incloïa el model de l’escenari generat, i els models referents als personatge, és a dir, els braços. També mitjançant la IDE, es van generar els diversos cubs, que representarien els dispositius de la xarxa com el router final. Posteriorment mitjançant la llibreria d’assets pròpia de Unity afegiem el controlador FPS que contenia la càmera principal. Per mitjà del Hierachy afegiem el model dels braços dintre del controlador perquè seguis els moviments de la càmera. Finalment calia texturitzar els objectes, creant els materials a través del visualitzador de l’escena i un altre cop el Hierachy. És important que durant aquest procés s’assignessin noms irrepetibles a cada objecte ja que actuarien com ID, també l’assignació d’un TAG identificatiu que els proporcionava una etiqueta per saber a quin conjunt d’objectes pertanyien (tag: cubs).

Un cop presentada l’escena tocava aplicar la lògica de la pantalla per mitjà dels scripts. Aquest scripts s’assignaven com a components als diferents objectes.

Els problemes més destacables durant el procés van ser totes les dificultats que es van esdevenir realitzant el control de col·lisions. El major problema va ser un error humà; les notificacions de consola a través de codi estaven desactivades, però no els errors ni les alertes. Aquest “petit” error va reportar força temps de projecte aturat fins que va ser “resolt”.

Un altra dificultat va ser la impossibilitat de canviar les textures en temps d’execució, per aquest motiu els cubs no canvien de textura, sinó que són substituits per uns altres amb la textura adient.

SCRIPTS En aquesta pantalla s’utilitzen cuatre scripts amb funcionalitats diverses, ubicats dins Assets/Scripts referent a la jerarquia de projecte prèviament explicada (apartat 6.3 Gestió de projecte amb Unity):

 Headbobber.js: Provinent de la carpeta Generic, assignat al controlador. Té la funció reproduir de l’efecte de les passes, generant un desplaçament vertical

51 UnderNET

alhora que vertical quan ens movem. Els atributs de velocitat i quantitat de capcineig.  Pause.js: Provinent de la carpeta Generic (dins Scripts), assignat al controlador i activat per mitjà de la tecla “ESC”. Proporciona la pausa a tots els scripts de l’escena i també obre un menú que permet una interacció. Aquesta menú ens ofereix la possibilitat de continuar el joc, tornar al menú principal, i ajustar certs paràmetres del joc (volum de l’àudio, qualitat dels gràfic, visualitzar propietats de l’escena i veure propietats del sistema).  cubeRotation.js: Propi de phase1, i assignat a tots els cubs. Realitza el moviment de rotació dels objectes. Configurable la velocitat.  characterCollisionScript.js: Propi de phase1, i assignat al controlador. És el script que gestiona les colisions, i en conseqüècia la lògica de l’escena. Aquí s’encarregarà de controlar el text que es motra, validar controls, etc. Aquestes col·lisions es gestionen a través de comprovacions amb el nom de l’objecte amb el qual col·lisiona el controlador.

MINIMAPA Durant la creació del model del laberint es va buscar que l’usuari pogués tenir punts de referència amb els quals es pogués situar dins el laberint. Es va comprovar que les ubicacions de caixes i amplituds dels passadissos no eren suficients, per aquest motiu es va recórrer a un minimapa que permetés saber al jugador en tot moment on es trobava.

Figura 55: Disseny final laberint

La creació d’aquest minimapa es va realitzar amb una vista zenital d’una càmera, aquesta vista es superposa a la càmera principal. La càmera és ortogràfica pel que se’ns mostra una imatge bidimensional, també s’afegeix una textura per sobre el controlador, que només serà visible per la càmera zenital, permetent situar al jugador dins el minimapa. Remarcar que la marca indica la orientació de cap on està mirant.

52 UnderNET

Figura 56: Vista escenari Maze

CITY: NIVELL 2 El segon nivell es composa d’un escenari de grans dimensions amb una fisionomia diferent de l’escenari anterior. Per realitzar-lo es va utilitzar les eines de la IDE de Unity, per a composició dels escenaris. Es van utilitzar els diversos pinzells per crear un contorn muntanyós que delimités els extrems dels terrenys, a la vegada que s’afegien petits accidents a l’interior. A continuació com ja succeïa al nivell 1, es van ubicar els objectes que compasarien l’escena en aquest cas els edificis, components i controlador del personatge (també afegiem el model de l’arma juntament amb els braços) i enemics.

Per la realització dels trets de l’arma va caler crear un nou objecte (partir d’un elemnt bàsic de Unity: cilindre), que es va convertir en un objecte prefab. Un objecte prefab, és un element base o plantilla, del qual se’n poden generar ‘n’ instàncies d’ell, en el cas de les bales d’un arma és força útil. Aquest objecte prefab no deixa de ser un gameobject, pel qual té totes les propietats de la classe pare pel que se li poden afegir components i scripts, que és el que realitzem en el cas de la bala.

Finalment apliquem els scripts corresponents a casdascún dels seus objectes.

Remarcar que els edificis són objectes (gameobjects) pel tenen totes les seves propietats. Que ens permet tenir-ne tants com vulguem, en les posicions que es desitgin tan sols accedint a les seves atributs. Com també convertir-los en objectes prefab per generar les conseqüents instàncies.

Els enemics apareixeran en funció de l’ubicació del personatge en un radi X definit per la pantalla.

53 UnderNET

SCRIPTS Al escenari city ja calen un nombre superior de scripts, alguns repeteixen i d’altres són nous (els prèviament explicats només s’anomenaran)

 Headbobber.js  Pause.js  IAFollow.js: Script ubicat a Generic, i assignat a cadascun dels enemics. Té la funció de guiar l’enemic per col·lisionar amb el personatge. Comporatment similar a un pathfinder sense ser-ho.  Shoot.js: Script ubicat a Generic, i ubicat al controlador del personatge (arma). Conté el listener del ratolí encarregar de generar la instància que farà de tret de l’arma.  killEnemy.js: Script ubicat a Generic, i ubicat al controlador del personatge (arma). S’encarrega de, passat un interval de temps destruir la instància de la bala. Sense aquest script ompliriem l’escenari de bales carregant el sistema, especialment crític ja que no tenim límit de trets.  killShoot.js: Script ubicat a Generic, i ubicat al prefab bullet (bala). És un controlador de col·lisions per saber si la bala ha impactat contra un enemic i en aquest cas eliminar-lo.  characterCollision.js: Script ubicat a phase2, i ubicat al controlador del personatge. Controla com en nivell anterior totes les col·lisons del personatge amb l’entorn, ja sigui contra l’enemic reduint vides fins acabar la partida, o bé validant els edificis de l’escenari, aplicant la lògica del joc.

IAFollow Donada la complexitat del script se’n fa una descripció més detalla. . Com s’ha comentat és l’encarregat de dirigir els enemics cap al personatge amb l’objectiu de ferir-lo.

Després de diverses proves amb llibreries de pathfinding (veure l’apartat Tecnologies no aplicades), es va decidir provar desenvolupant un script més simple. Es tracta d’un desplaçament lineal ja que les característiques de l’escenari permeten aquest tipus de moviment. És a dir, es mou d’un punt A a B en línia recta, ja que és el camí més directe i ràpid. Disposarem també de diverses velocitats en funció a la distància de l’objectiu, fàcilment configurables.

Els dos elements de control seran l’orientació que es fonamentarà en la posició del personatge amb el que sempre estaran orientat a ell, i la posició que ve donada pel càlcul que es mostra a continuació:

푉3푓 = 푉3푖 ∗ 푣푒푙표푐푖푡푎푡 ∗ ∆푡푒푚푝푠

54 UnderNET

Com que la velocitat ve donada en funció de la distància (més lluny, implica més velocitat) cal calcular-la, això es calcula per mitjà del mòdul del vector dels dos punts:

2 2 퐷푖푠푡à푛푐푖푎 = (푝표푠푋푑푒푠푡í − 푝표푠푋표푟푖푔푒푛) + (푝표푠푌푑푒푠푡í − 푝표푠푌표푟푖푔푒푛)

Important: Qui conegui el funcionament matemàtic dels vectors trobarà a faltar, l’arrel quadrada a l’equació. Això es deu, a que l’arrel té un alt cost computacional pel que evitarem fer-la servir quan no sigui estrictament necessari. L’error generat al no aplicar-la en cas de comparació de distàncies pot ser despreciable, ja que no implicarà una desviació prou important com per ser considerada [18] .

TESTEIG UX Les decisions que es van platejar al testejar el nivell eren:

 Nombre d’enemics: Es van decidir 3, ja que era el primer cop que se li dona al jugador l’arma.  Nombre de vides: Disposarem de 3 vides, ja que l’usuari no sap la ubicació per on sortiran (podria tenir-los a l’esquena).  Velocitat de desplaçament del personatge que portem: Calia ajustar-la ja que ens trobem amb un escenari de grans dimensions, i tenim acció. La velocitat és 1’5 vegades superior respecte la pantalla anterior.  Quantitat de munició: És il·limitada, ja que es pot errar fàcilment els tirs.  GUIs: Es van realitzar nous dissenys dels GUIs perquè els diàlegs fossin clarament visibles per l’usuari (consoles, impactes...).  Velocitats dels enemics: Es va afegir els diversos tipus de velocitats als enemics, ja que si es trobaven molt lluny trigaven a arribar, i si es trobaven a prop podia ser molt difícil o impossible eliminar-los. Trams delimitats a 600 i 200 unitats.

Figura 57: Vista escenari City

55 UnderNET

DEVICE: NIVELL 3 Aquest nivell s’utilitzen mecàniques dels nivells anteriors dels nivells anteriors amb un grau més alt de dificultat, i afegint algun detall que atorgués novetat.

El procediment utilitzat, va ser el mateix que en els escenaris anteriors. Creació d’un nou terreny composat d’un únic pla, integració dels diversos objectes a l’escena: personatge (controlador i models 3D), enemics (7 unitats), GUIs, prefabs, plataformes mòbils i models dels cubs (interficies o ports). Els límits de l’escenari es van realitzar amb cubs propis de la IDE per reduir costos.

A continuació varem afegir els scripts.

SCRIPTS Donada la naturalesa de la pantalla la majoria dels scripts es repeteixen a excepció de els col·lisions (que contenen la lògica) i les plataformes:

 Headbobber.js  Pause.js  IAFollow.js  Shoot.js  killEnemy.js  killShoot.js  characterCollisionL3.js: Script dins de la phase3, i ubicat al controlador del personatge.  P1move.js, P2move.js, P3move.js, P4move.js, P5move.js: Scripts dins de la phase3, i ubicat a cadascuna de les plataformes i als portals 4 i 5. Són els scripts encarregats dels desplaçaments sobre el pla XZ, tants de les plataformes com dels cubs. Són idependents ja que calen valors i coordinaciosn diferents de cara a la jugabilitat.  verticalPlatform.js: Script dins de la phase3, i ubicat a cadascuna de les plataformes de desplaçament vertical. S’encarregan dels desplaçament en l’eix Y. Simula el comportament d’un ascensor.

BALANÇ DE JOC Com que l’usuari parteix de cert aprenentatge, aquí s’hi afegeixen onades d’enemics fet calia calibrar. Es va optar per 7 enemics per tongada ja que apareixen de manera aleatòria per l’escenari fet que proporciona la dificultat adequada per poder eliminar-los a tots simultàniament. Partíem de l’experiència de valors respecte el nivell anterior.

Altres decisions importants van ser:

56 UnderNET

 Calibrar els temps entre onades: Probablement una de les decisions més crítiques, ja que calia que fossin prou espaiades per donar temps a realitzar les tasques d’investigació i de plataformes (esperar que plataforma vertical baixi) i que requereixin cert “estrès” aquests atacs.  Velocitats del jugador: Reajustar els valors a les dimensions de l’escenari i proporcionar més velocitat per poder competir amb major nombre d’enemics. També cal tenir en compte que el personatge té més habilitat fet que ha de repercutir en la jugabilitat.  Velocitats plataformes: Calia coordinar les plataformes perquè totes fossin accessibles.  Límits de l’escenari: Durant els testejos es va comprovar que des de les plataformes aèries era viable saltar el murs que delimitaven l’escenari, pel que es van haver de crear murs invisibles més alts.

Figura 58: Vista Escenari Device

MENU I EXPLICATIUS La navegació a través del joc es realitza a través d’un menú principal que permet sortir del joc, visualitzar quins són els controls, els crèdits i iniciar la partida. També trobarem pantalles explicatives dels objectius del nivell just abans de començar.

SCRIPTS  Play.js, Quit.js, Controls.js, Credits.js, Back.js: Scripts dins de la menu, són els encarregats de les accions dels botons, que generen animacions i dirigieixen a les escenes següents.

57 UnderNET

 toLevel1.js, toLevel2.js, toLevel3.js: Scripts dins de menu, són redireccionen a l’escena corresponent al nivell.

Figura 59: Pantalla menú principal

6.5 EXPORTACIÓ

Un cop desenvolupat el joc, l’últim pas és l’exportació. Unity ofereix exportar a un gran nombre de plataformes pel que donat el moment i amb les degudes modificacions, podria ser viable que tingués una versió per a palataforma mòbil ja sigui tauleta o smartphone (iOS, Android, WP8). Com ja s’ha explicat prèviament la plataforma destí era PC sistema operatiu Windows, ja que era el sistema més extens i era la opció més viable de cara al módul de telemàtica.

Així doncs, l’opció sel·leccionada Windows amb arquitectura x86, per fer accessible a un major nombre de dispositius.

Dins del Inspector s’escollien la resta de propietats del joc:

 Nom del joc, companyia propietària i icones.  Sistema de distribució: Standalone, aplicació única.  Resolució de pantalla: Es va escollir una resolució estàtica de 1024x768 perquè fos reproduïble per més gent  Que no s’executés a pantalla completa per defecte, degut a la baixa resolució.

58 UnderNET

6.6 TECNOLOGIES NO APLICADES

En aquest apartat es parlarà de totes tecnologies les quals s’han treballat durant el procés del projecte però que al final per motius diversos no s’han aplicat en la implementació final.

GENERADOR DE LABERINTS De cara al primer nivell es va plantejar la possibilitat de fer un laberint aleatori, és a dir, que cada vegada que es generés el nivell 1 (maze) el jugador es trobés amb un escenari diferent.

Aquesta opció era força viable des del punt de vista tecnològic, ja que es composava de crear una matriu, que representés una quadrícula en la que dins es trobaria l’escenari. Donada la facilitat de crear element com cubs de manera directa mitjançant codi, es podrien generar les parets que composarien el laberint. Calia crear un algoritme que generés aquesta matriu, a través d’internet es podien trobar forces scripts que ho generèssin o bé expliquèssin com fer- los [19].

El mètode escollit es de considerar cada quadrícula com una cel·la amb els “murs” aixecats. Partint d’aquest concepte s’aplicava l’algoritme recurdiu conegut com Depth-content search [20]. Els passos consisteixen en:

1) Comença a una cel·la aleatòria de la matriu 2) Mira a un veí aleatori, el qual encara no hagi estat. 3) Si et trobes un, treu el “mur” que els separa. Sinó trobes cap tornes a la cel.la anterior 4) Repetim els punts 2 i 3, abans que hagis totes les cel·les de la graella.

Figura 60: Arbre representatiu del comporatment Depth Content-Search

59 UnderNET

Aquest era l’algortime que s’anava a aplicar però després de testejos veient els diversos resultats que donava (representacions 2D) alguns laberits eren força complexos i podien perjudicar la jugabilitat, per aquest motiu es va escollir un realitzar un laberint a “mida” de cara a la demo. Recordar que en una primera instància quan es va descartar aquest algoritme no es contemplava el afegir una càmera zenital d’ajuda.

Per aquest motiu finalment es va descartar el generador de laberints.

Figura 61: Generació de laberints

PATHFINDING El pathfinding ha sigut una de les grans barreres del projecte, abans d’escollir el mètode finalment implementat es van treballar i investigar amb diverses llibreries i algoritmes de pathfinding.

Unity de manera natural ja ofereix mecanismes de pathfinding dintre de la seva IDE, fet que hauria facilitat en gran mesura el desenvolupament del joc. Però desgraciadament eren propietats de la versió de pagament, així que es va tenir que recórrer a alternatives.

A* LIBRARY Astar Library (A* Library), és una llibreria basada en els algoritmes de grafs anomenats algoritmes de estrella (al 1968 per Peter E. Hart, Nils J. Nilsson y Bertram Raphael) [21].

És un algoritme que si es compleixen una sèrie de requisits, sempre troba el camí amb menor cost entre node9 origen i el destí. El funcionament d’aquest algoritme és força complex, ja que es composa d’una barreja d’algoritmes recursius que funcionen en funció dels seu pesos10.

9 Node és com anomenen el centre de l’objecte sigui quin sigui 10 El pes és aquell “cost” que nosaltres considerem que tingui una acció

60 UnderNET

El funcionament d’aquest algorisme és aquest:

1) Afegir el node inicial de la llista oberta. La llista oberta és allà on emmagatzemarem totes aquelles ubicacions que considerem que calen verificar. 2) Repetir a. Buscar la plaça amb el cost F11 més baix a la llista oberta. Ens referim a això com la “plaça actual”. b. Moure-la a la llista tancada. Llista on s’emmagatzemen les places que ja no cal validar. c. Per a cadascuna de les 8 caselles adjacents a la plaça actual fer: . Si no es pot anar o si està a la llista tancada, la ignorem. En cas contrari feu el següent:  Si no està a la llista, afegir-la a la llista oberta. Fer de la plaça actual els pares d'aquesta plaça. Calcular F, G, H i els costos de la plaça.

 Si ja està a la llista oberta, comprovar si aquest camí a la plaça és el millor, amb cost G com a referència. Un cost menor G vol dir que aquest és un millor camí. Si és així, canvieu el pare de la plaça de la plaça actual i recalculem els G i F puntuacions de la plaça. a. S’atura quan: . Afegim la plaça de destí a la llista tancada, a la qual s'ha trobat la ruta d'accés. . No troben per la plaça de destí, i la llista oberta és buida. En aquest cas, no hi ha camí. 3) Es desa el camí. Anem enrere des de la plaça de destí, anar des de cada casella a la casella del pare fins arribar al node d’inici.

Com es pot comprovar realment és un algorisme amb un alt cost tant computacional com d’implementació. Malgrat això, ja hi ha llibreries que l’implementen i és aquesta la que es va escollir A* Pathfinding Project [22] desenvolupada per Aron Granberg compatible amb Unity.

11 F = G (cost del punt inicial al pas següent segons el camí seguit fins el moment) + H (cost estimat fins el destí final)

61 UnderNET

La utilització d’aquesta llibreria implicava un cost elevat per a la nostra implementació, ja que calia fer un anàlisi de l’escenari prèviament mitjançant un dels complements de la llibreria l’Editor.

El funcionament era afegir un objecte buit dins l’escena al qual li aplicaven el complement del A* Pathfinder, amb aquest objecte s’escanejava l’escenari, generant un mapa en forma de graella on es marcaven les cel·les que es podien travessar i quines no. En la següent podem observar-ne un exemple on la part verda fa referència als punt on es pot passar i els marrons on hi haurà col·lisió.

Figura 62: Representació resultat escaneig de l'escenari amb A* Project

Posteriorment, s’aplicaven als objectes que volien que seguissin un altre complement de A*, on es podia escollir l’objecte destí i adjuntàvem el mapa generat prèviament.

Això s’enfrontava de manera directa amb la idea del joc, on volien que els escenaris fossin dinàmics poden ubicar els elements en funció de la partida, especialment en el nivell de la ciutat. Ja que, com aquesta llibreria, requereix d’un escenari prèviament definit a l’inici de la partida. Per aquet motiu finalment es va descartar, però donada la potència d’aquesta llibreria s’ha mantingut, per si fos necessària per a futurs desenvolupaments.

XML / DLLs Un dels punts crítics que s’havien de desenvolupar en el transcurs del projecte era aconseguir els nivells de joc es crein en funció de dades reals de la xarxa des d’on s’està jugant. El joc ja ha sigut dissenyat perquè pugui ser fàcilment aplicada per mitja de variables. Com ja s’ha comentat les variables en aquesta versió han estat introduïdes estàticament.

L’objectiu seria aconseguir-les per mitjà de diversos sistemes:

 DLLs: Aquest seria el mètode ideal, i un dels motius pel qual es va escollir aquest motor gràfic. La llibreria permetria executar de manera ràpida les funcions telemàtiques i poder recuperar els valors de manera directa. Aquest apartat corresponia al mòdul de telemàtica, per poder mirar la viabilitat i posteriorment comprovar la integració dins el projecte.

62 UnderNET

 XML: La segona via era més costosa a nivell computacional, ja que requeria l’escriptura i lectura d’un fitxer que contingués les dades. El tipus de fitxer que s’hauria escollit seria en format XML. Donat el retard amb la investigació del mòdul de telemàtica, es va començar a decantar pel métode XML. Un altre cop problemes amb el mòdul de telemàtica no va permetre definir les característiques finals que havia de tenir el fitxer. Tot i això, es va definit un primera estructura de com hauria de ser el fitxer el cas que es desenvolupés. Aquí es pot observar una versió de com hauria de ser:

192.78.16.0 00-B0-D0-86-BB-F7 PC 192.78.16.1 00-B6-A0-87-EE-A1 ROUTER

63 UnderNET

7. RESULTATS

El projecte underNET, amb els seus tres mòduls, pretenien generar un joc que s’adaptés a l’entorn virtual al qual es trobava el jugador. Composats per l’apartat de telemàtica (anàlisi de la xarxa), d’àudio (generació i implementació de sons i música) i la interactiva ( disseny i implementació del videojoc).

S’aspirava a una primera experiència de joc completa, ja que es tenia la perspectiva d’una evolució en futurs projectes. A data de finalització d’aquesta memòria només s’ha completat un dels tres mòduls: l’interactiu; el qual s’ha explicat en aquesta memòria. De manera que s’ha obtingut una primera versió del joc, però sense ser adaptativa a l’entorn com s’exigia a l’inici del projecte, ni té el contingut d’àudio que oferiria una versió més profunda i enriquidora d’experiència de joc.

Dit això pel que fa referència a aquest mòdul en concret s’ha assolit la major part dels objectius. S’ha desenvolupat un disseny de joc que es corresponia amb els conceptes d’edutaiment, sent fidel a l’esperit original amb el qual s’engegava el projecte. Aquest disseny manté les directrius que pugui ser adaptable a l’entorn del jugador.

Partint d’aquest disseny s’ha generat una versió jugable del joc. Aquesta versió està adaptada per a futures incorporacions dels altres dos mòduls, i possibles evolucions de la part interactiva. Des del punt de vista planer, això vol dir que només caldria omplir les variables amb els valors reals, i fer alguns ajustos per encabir-hi bé els mòduls externs.

Figura 63: Resultat dls nivells de joc

A nivell d’experiència d’usuari els primers testejos realitzats han reflectit una resposta satisfactòria dels jugadors, especialment dins dels apartats d’acció, ja que durant uns intervals de 5-10 minuts han interactuat activament, malgrat els èxits i fracassos. El que implica un bon símptoma a nivell de jugabilitat.

64 UnderNET

8. CONCLUSIONS

Podem afirmar que el resultat del mòdul interactiu és satisfactori, ja que s’ha aconseguit assolir tots els objectius inicials. Ens trobem davant d’una demo finalitzada completament, essent una versió usable que permet assentar les bases per a la finalització d’un serious game. Compleix les característiques pròpies de l’edutaiment ja que proporciona certs coneixement, mentre l’usuari gaudeix, oblidant-se que es troba davant d’un joc educatiu. També permet la incorporació dels altres dos mòduls (fora de l‘abast d’aquest projecte) per a un enriquiment del resultat assolit.

A nivell crític matisar, que no s’ha pogut arribar a la presentació òptima a nivell gràfic, degut a motius tècnic (especialment dins l’apartat d’il·luminació), ni una intel·ligència artificial (IA) prou depurada com s’hauria desitjat. En aquest cas per motius de temps, ja que es va decidir prioritzar obtenir una versió que pogués considerar-se acabada. Relacionat amb la IA, els testejos d’usabilitat s’han hagut de centrar en un espectre petit, pel que les dades obtingudes no són menyspreables, però no prou significatives com per ser totalment representatives.

Dit això, el projecte UnderNET ha tingut que enfrontar-se a diversos canvis de rumb durant el transcurs del seu desenvolupament, provinents de la gestió i coordinació de les altres parts del desenvolupament. Es va iniciar, realitzant en un inici els tres mòduls units per més endavant separar-se i desenvolupar-se en forma aïllada. El projecte estava estructurat en sprints (mitjançant eines com Teambox i Trello), veient que no es podia mantenir la planificació inicial, es va flexibilitzar la gestió del projecte, fins el punt que es va sol·licitar la paralització temporal dels altres mòduls. En aquest moment es va ramificar perquè el projecte no s’estanqués per complet.

Aquest projecte va poder continuar adaptant-se a les noves circumstàncies. Generant en solitari un nou disseny del joc que complís els requisits i amb moltes manques d’informació sobre el mòdul telemàtic especialment: quina informació es podia obtenir, coneixements telemàtics a mostrar, interconnexions... Però sempre mantenint un canal obert per a la futura incorporació dels altres mòduls. Fins finals del mes de juliol, no es coneixia la cancel·lació definitiva de tots els altres mòduls, quedant penjades algunes de les característiques d’aquest projecte, pel que es va haver de reajustar alguns detalls, per poder tenir una versió executable d’aquest mòdul satisfactòria. Aquests factors “externs” ha produït un empobriment del que podia haver sigut el resultat final. Es remarquen aquests esdeveniments perquè permeten l’anàlisi dels resultats amb un altre prisma, i fan que les conclusions del producte final siguin més positives.

A nivell gestió de projecte si que es conclou que es va realitzar una planificació excessivament optimista (a l’annex es pot observar al calendari dins el Pitch la planificació inicial) pel que fa a temps i costos. I que malgrat si es va intentar que es va intentar un desmarcatge entre els diversos mòduls per evitar una dependència, només es va assolir a

65 UnderNET

mitges, ja que al final si van influir en les altres branques. És veritat que moltes informacions bàsiques requerien un diàleg, pel que hauria calgut una duplicitat de tasques perquè en cas que caigués una els altres poguessin continuar, fet que en el moment de la planificació no es va plantejar.

66 UnderNET

9. LÍNIES DE FUTUR

La primera línia de futur és la integració dels móduls tant de telemàtica com d’àudio un cop estiguin enllestits. L’acoplament suposarà un gran salt en la qualitat del joc ja que permetrà millorar la seva experiència. Aquest acoplament pot suposar modificacions respecte determinades parts del codi.

L’apartat de telemàtica oferirà la possibilitat d’interactuar amb un entorn real, amb el que aconseguirem ampliar les partides, fent que siguin úniques cada iteració. També permetrar satisfer la curiositat de determinats jugadors a la recerca.

El mòdul d’àudio permetrà enriquir el joc, actiavnt un sentit del jugador (l’oïda), que no s’implicava en l’activitat.

Des del punt de vista interactiu les millores que s’haurien d’aplicar:

 La millora de la IA dels enemics, afegint un pathfinding real que reaccionés en un escenari dinàmic, ja que no sempre tindrà el mateix aspecte. Algun tipus d’evolució del A* Library (explicada anteriorment).  Ressolució de determinats bugs que poden succeïr en determinades col·lisions.  Afegir varietat d’enemics i missions, el que permetria evitar una possible monotonia del joc, i la conseqüent desafecció.  Permetre els salts entre diverses ciutats, és a dir, a xarxes superiors ampliant el nivell 2. Implicaria una recreació més acurada del que és el comportament de les xarxes aniuades.  Aplicació de millores en la il·luminació i textures: com per exemple les ombres o autoil·luminació que no s’han pogut aplicar al no disposar d’una versió de pagament.

A llarg terme, seria molt interessant:

 La integració de modes cooperatius, que permetessin la interacció de diversos jugadors dins el mateix escenari des de diversos dispositius. Per exemple si 2 jugadors estan al mateix nivell de xarxa alhora es puguèssin veure i interaccionar. Una socialització pot implicar un al·licient afegit, ja que alimenta la vessant social del jugador.  Exportació per a altres plataformes, smartphones per exemple. Sumat al punt anterior augmentaria exponencialment el potencial. Poder jugar en qualsevol

67 UnderNET

moment facilitaria l’accés al joc, i a partides esporàdiques que d’altra manera no succeirien.  Poder ser jugat a través d’un navegador d’internet (similar al punt anterior). Facilitar l’accés a plataformes que no són un PC amb Windows.

68 UnderNET

10. ESTUDI DE COSTOS

La realització d’aquest projecte ha suposat una dedicació final 11 mesos, els quals s’han fragmentat en la investigació i la implementació. La implicació temporal al llarg d’aquest període s’ha incrementat a mesura que la implementació s’anava duent a terme.

 Del període de novembre a febrer es van realitzar l’apartat d’investigació, que contenia tant l’apartat tecnològic com teòric del projecte i la definició del projecte, què es pretenia assolir.  De febrer a maig, es va realitzar la primera versió del disseny del joc (GDDv1), com també l’aprenentatge de la tecnologia escollida. Paral·lelament es dissenyaven els primers elements artístics del joc.  Maig a juny s’assolia una primera plantilla tècnica sobre la qual es treballaria. A final d’aquest període es realitzava el disseny final (GDDv2).  Juliol i agost, es realitzava la integració de l’apartat artístic i la implementació dels nivells. Final del període primeres proves de testeig.  Setembre correccions tècniques i a nivell d’experiència d’ús. Redacció de la memòria

A nivell econòmic el cost ha sigut nul, ja que es disposava del material per a la seva realització sense cap cost afegit. L’ús d’elecció de llicències gratuites i d’estudiant, oferien la possibilitat d’un accés a software sense cost. La bibliografia s’ha fonamentat en articles, i llibres de distribució pública pel que tampoc ha influit.

69 UnderNET

ÍNDEX DE FIGURES

Figura 1: Perfil de jugadors a Espanya l'any 2012 ...... 4 Figura 2: Fotograma d'un joc de Cisco amb perfil Quizz ...... 7 Figura 3: Fotograma del joc “Edge Quest 2” ...... 8 Figura 4: Fotograma del joc Binary Game ...... 8 Figura 5: Fotograma “Math Blaster” ...... 10 Figura 6: Fotograma “Cómo funcionan las cosas” ...... 10 Figura 7: Exemple de serious game ...... 11 Figura 8: Gràfica representativa dels percentatges de jocs basats en l'edutainment ...... 12 Figura 9: Gràfica d’utilització de sistemes operatius en dispositius mòbils ...... 15 Figura 10: Gràfica d’utilització de sistemes operatius a nivell d’escriptori...... 15 Figura 11: Jerarquia dexarxes ...... 16 Figura 12: Comportament del joc UnderNET versió 1 ...... 17 Figura 13: Estructura de navegació de menús del joc ...... 18 Figura 14: Diagrama estructura del joc ...... 19 Figura 15: Logotip projecte UnderNET ...... 20 Figura 16: Exemple d'estètica de Matrix ...... 20 Figura 17: Exemple d'estètica de Tron ...... 20 Figura 18: Exemple ciutat Tron ...... 27 Figura 19: Exemple ciutat Tron Legacy ...... 27 Figura 21: Frame sèrie televisiva ReBoot ...... 28 Figura 22: Fotograma del videojoc Portal ...... 28 Figura 23: Moodboard ...... 29 Figura 24: Paleta de colors principal ...... 29 Figura 25: Paleta de colors secundaria ...... 30 Figura 26: Consola de diàleg dreta ...... 31 Figura 27: Consola de diàleg Esquerra ...... 32 Figura 28: Marcador del minimapa ...... 32 Figura 29: GUI d'impacte ...... 32 Figura 30: GUI de nova onada d'enemics...... 32 Figura 31: GUI enemics apropant-se ...... 33 Figura 32: GUI dels botons de navegació ...... 33 Figura 33: Desenvolupament laberint amb 3D Studio Max ...... 34 Figura 34: Vista frontal edificis pantalla City ...... 34 Figura 35: Vista zenital de la plataforma ...... 35 Figura 36: Vista lateral edificis pantalla City ...... 35 Figura 37: Vista lateral de la torre central de la City ...... 36

70 UnderNET

Figura 38: Perspectiva de la torre central de la City ...... 36 Figura 39: Plataforma mòbil escenari Device ...... 36 Figura 40: Braços personatge ...... 37 Figura 41: Model arma personatge ...... 37 Figura 42: Model enemic ...... 38 Figura 43: Model cube device ...... 38 Figura 44: Textures cubs pantalla maze ...... 39 Figura 45: Textures complementaries escenaris ...... 39 Figura 46: Textures basades en el metall per a escenaris i components ...... 40 Figura 47: Textures comodí ...... 40 Figura 48: Demostració motor gràfic Unreal Engine 3 ...... 42 Figura 49: Evolució del motor CryEngine ...... 43 Figura 50: Demostració del motor CryEngine 3 ...... 44 Figura 51: Demostració del motor Unity 4 ...... 45 Figura 52: IDE de Unity ...... 47 Figura 53: Entorn Microsoft Visual Studio 2012 ...... 48 Figura 54: Arbre de carpetes de la carpeta Assets ...... 50 Figura 55: Disseny final laberint ...... 52 Figura 56: Vista escenari Maze ...... 53 Figura 57: Vista escenari City ...... 55 Figura 58: Vista Escenari Device ...... 57 Figura 59: Pantalla menú principal ...... 58 Figura 60: Arbre representatiu del comporatment Depth Content-Search ...... 59 Figura 61: Generació de laberints ...... 60 Figura 62: Representació resultat escaneig de l'escenari amb A* Project ...... 62 Figura 63: Resultat dls nivells de joc ...... 64

71 UnderNET

BIBLIOGRAFIA

[1] Ipsos MediaCT, «Videogames in Europe: consumer study,» [En línea]. Available: http://www.isfe.eu/sites/isfe.eu/files/attachments/spain_-_isfe_consumer_study.pdf. [Último acceso: 4 9 2013].

[2] Cisco Systems Inc., «The Cisco Learning Network,» [En línea]. Available: https://learningnetwork.cisco.com/community/learning_center/games. [Último acceso: 3 9 2013].

[3] Cisco Systems Inc., «The Cisco Learning Network,» [En línea]. Available: https://learningnetwork.cisco.com/docs/DOC-7634. [Último acceso: 4 9 2013].

[4] Cisco Systems Inc., «The Cisco Learning Network,» [En línea]. Available: https://learningnetwork.cisco.com/docs/DOC-1803. [Último acceso: 4 9 2013].

[5] Davidson, Math Blaster, 1994.

[6] Dorling Kindersley, Cómo funcionan las cosas, 1994.

[7] E. Gómez Milán y E. Salazar, «Capítulo 20: Flujo y placer,» [En línea]. Available: http://www.ugr.es/~setchift/docs/conciencia_capitulo_20.pdf. [Último acceso: 21 09 2012].

[8] U. Ritterfeld, M. Cody y P. Vorderer, «Serious Games: Mechanisms and Effects,» de 2009, London, UK, Routledge, p. 18.

[9] N. Montes, «Blogs CEU,» 11 3 2013. [En línea]. Available: http://blog.uchceu.es/informatica/ranking-de-sistemas-operativos-mas-usados/. [Último acceso: 21 9 2013].

[10] S. Lisberger, Dirección, Tron. [Película]. USA: Walt Disney Productions, 1982.

[11] J. Kosinski, Dirección, Tron Legacy. [Película]. USA: Walt Disney Pictures, 2010.

[12] L. W. Andy Wachowski, Dirección, Matrix. [Película]. USA: Warner Bros, 1999.

[13] J. G. P. M. I. P. Gavin Blair, Dirección, ReBoot. [Película]. Canada: Mainframe Entertainmen, 1994-2002.

[14] Valve Corporation, Portal, 2007.

72 UnderNET

[15] JAW1002, Pillar of Autumn.

[16] JAW1002, Portal turret.

[17] WafflesAu, Portal Companion Cube With Heart.

[18] nitsnets | studios, «Tips matemáticos de geometría para programación de videojuegos,» 10 8 2012. [En línea]. Available: http://www.lostiemposcambian.com/blog/as3/tips- matematicos-geometria-programacion-videojuegos/. [Último acceso: 12 9 2013].

[19] Unknown, «MazeWorks - How to build a maze,» [En línea]. Available: http://www.mazeworks.com/mazegen/mazetut/. [Último acceso: 11 09 2013].

[20] W. Collaborator, «Wikipedia,» [En línea]. Available: http://en.wikipedia.org/wiki/Depth- first_search. [Último acceso: 11 09 2013].

[21] W. Collaborator, «Wikipedia,» [En línea]. Available: http://en.wikipedia.org/wiki/A*_search_algorithm. [Último acceso: 11 9 2013].

[22] A. Granberg, «A* Pathfinder Project,» [En línea]. Available: http://arongranberg.com/astar/. [Último acceso: 10 09 2013].

[23] D. Davidson, Well Played 1.0: Video Games, Value and Meaning, D. Davidson, Ed., ETC Press, 2009.

[24] D. Davidson, BEYOND FUN: Serious Games and Media, D. Davidson, Ed., ETC Press, 2008.

[25] C. Nutt, «GDC: Game Design Workshop: Mechanics, Dynamics, Aesthetics,» Gamasutra, 18 2 2008. [En línea]. Available: http://www.gamasutra.com/php- bin/news_index.php?story=17464#.UJzljcVmKG4. [Último acceso: 2013 9 22].

[26] Cisco Systems, «Cisco Networking Academy,» [En línea]. Available: http://www.academynetspace.com/?pop=1. [Último acceso: 22 9 2013].

[27] Cisco Systems, «Cisco Learning Games,» [En línea]. Available: http://www.medcalf.com/games/cisco_games/index.html. [Último acceso: 22 9 2013].

[28] Cisco Systems, «Cisco CCENT Mind Share Game,» [En línea]. Available: http://dl.acm.org/citation.cfm?id=1942212&coll=DL&dl=GUIDE. [Último acceso: 22 9 2013].

73 UnderNET

ANNEX

74

Índice

• Presentación o Problemática o Competencias o Solución • Proyecto o Módulos o Tecnologías o Calendario o Costes • Líneas de futuro • Preguntas

2

Problemática

• Teoría • Ejercicios • Prácticas • Titulaciones o CCNA o CCNP o …

4 Problemática

• Teoría • Ejercicios • Prácticas • Titulaciones o CCNA o CCNP o …

5 Problemática

TARGET

Elementary School 16% 5% 40% Preschool and Below College, Adult and Senior 39% Middle and High School

6 Competencia

7 UnderNET World

8

Módulos

Víctor Rodríguez Joan Vidal Alfredo Giraldós

10 Tecnologías • Telemática

• Interactiva

• Audio

11 Calendario

12 Costes PC’s 1500€ x3

Unity 3D 1500€ ProTools 677€ Sonar X1* (300€)* + (500€)* Varios* ______6677€ (7100€)*

13 Líneas de Futuro • Multi-player o Social – interacción usuarios o Seguimiento – ID usuario • Niveles personalizables o Adaptables a diversos cursos (routing,…) o Mejorar experiencia de usuario • Nuevos comandos o Nmap, arpspoof…

14 Preguntas

15 ENGINYERIA I ARQUITECTURA LA SALLE - URL

GDD: UnderNET World Networking Serious Game

Alfredo Giraldós Víctor Rodríguez Joan Vidal

27/03/2013

Game Design Document del proyecto UnderNET World Índice:

1. Introducción 2. Descripción 2.1 Título 2.2 Ambientación 2.3 Género y público objetivo 2.4 Historia del videojuego 2.4.1 Texto narrativo Introducción 2.5 Guión del videojuego 3. Mecánicas de juego 3.1 Reglas juego 3.2 Mecánicas de juego 3.3 User Inteface 4. Art Work 4.1 Moodboard 4.2 Diseño Escenarios 4.3 Diseño Personajes 4.4 Paletas Colores 4.5 GUI 5. Audio 5.1 Escenario Principal 5.2 Minijuegos 5.3 Transiciones 5.4 Menú

1. Introducción:

- El juego, con título “UnderNET World”, es un Serious Game cuya temática está orientada a las Redes de Datos que hay actualmente. Va dirigido tanto a un público que se esté iniciando en este campo, mayoritariamente universitarios, o ya sea un experto.

2. Descripción:

2.1 Título

El título del juego es “UnderNET World”.

2.2 Ambientación

El juego está ambientado en un escenario del tipo futurista como por ejemplo Matrix, Tron, etc.

El escenario da una sensación de amplitud para parecer que no se acaba nunca pero el personaje tendrá limitada su zona de movimiento. Dentro y fuera de la zona de movimiento del personaje se generan los elementos que harán referencia a dispositivos que se pueden encontrar en una red de los cuales solo el personaje podrá acceder a aquellos que se encuentran de verdad en la red explorada, los demás elementos generados son estéticos para dar una sensación de un escenario grande.

Cuando se accede a otra red a través de un dispositivo, en este caso un router, el escenario se vuelve a generar con los dispositivos encontrados en la red actual.

2.3 Género y público objetivo

Genero

Es un juego de carácter educativo, concretamente un Serious Game.

Público objetivo

Al tratarse de un Serious Game su público ya viene definido que son universitarios, adultos y personas mayores. Este tipo de público es minoritario en los juegos educativos como se puede observar en el siguiente gráfico:

El juego está orientado a este público debido a que la temática del juego trata sobre las redes informáticas las cuales se estudian en la universidad o en academias específicas.

2.4 Historia del juego

Nos encontraremos en el papel de un estudiante de la universidad de La Salle de unos 20 años de edad, el cual va a ser absorbido por la red y va entrar en nuevo mundo virtual. El personaje estará inmerso en este nuevo mundo perdido donde buscará la salida recorriéndolo.

Este mundo virtual está contaminado por un virus/malware, que corrompe los elementos de la red, con lo que no se comportan de la manera adecuada. El resto de programas asustados por su rápida expansión y la incapacidad de luchar contra él pedirán ayuda al estudiante. Éste es el motivo por el cuál a medida que se desarrolla la historia descubrirá que está absorbido.

Píldoras de historia que conocerá:

2.4.1 Texto narrativo de introducción

Era la típica semana, hasta arriba de prácticas, sin tiempo para estudiar y ya no digamos un ápice de vida social fuera de la facultad…

El ordenador marcaba las 21:17, resoplé un poco y me desperecé un poco en la silla, miré alrededor y no había ni un alma en la sala. Me encontraba en la planta -2, en los laboratorios de telemática de la universidad, aquellos que laSalle Barcelona les gusta tanto presumir de CISCO NetAcad, si habéis estado por allí creo que sabréis a cuales me refiero. Pero volviendo a mi historia; solo, acabando la práctica que debía entregar en la próximas 48h cuando hubo una bajada de tensión, las luces parpadearon y las placas de un par de ordenadores emitieron un pitido. Me apresuré a guardar las evoluciones de la práctica, no tenía ninguna intención de perder todo el trabajo hecho, pero ya era tarde…

El ordenador se había bloqueado, y por muchas teclas apretara y maldiciones que le lanzara, él seguía sin responder. Me maldije a mi mismo por no ser cuidadoso y no hacer copias de seguridad, y fue en ese preciso instante cuando la pantalla empezó a brillar de una manera extraña, la interfaz empezó a cambiar, convirtiendo toda la pantalla en una consola.

En la consola empezaron a aparecer mensajes con textos de ayuda, extrañado volví a recorrer con la mirada la sala en busca de alguien que estuviera gastando una broma, pero nadie. La pantalla continuaba mostrando cada vez más mensajes diciendo lo mismo. Me levanté y me dirigí al final de sala donde estaban situados todos lo racks con la intención de desconectar mi terminal de la red, y que nadie lo ejecutara remotamente. Ya mientras caminaba hacia allí sentí que algo no encajaba, pero lo achaqué al cansancio. Una vez llegué al rack, busqué el cable que correspondía a mi fila mientras esa inquietud iba en aumento. Lo localicé, y lo toqué…

3. Mecánicas de juego:

3.1 Reglas de juego

El juego estará dividido en dos mecanismos, que podrán ser escogidos en el menú principal.

Menú

Escenario Historia General

Minijuego 1

Minijuego 2 Menú Arcade ...

Minijuego N

Ranking

Historia

Cada vez que el jugador ejecute el juego el escenario general por el cual se deberá desplazar se generará en función de la red a la cual está conectada.

El jugador deberá navegar por el escenario en busca de diversos retos que le permitan acceder a mini juegos que pondrán a prueba sus conocimientos. Esos mini retos tendrán mecánicas de juego diversas (véase apartado 3.2), que deberán ser resueltos de manera satisfactoria para tener una recompensa dentro de la línea principal del juego.

Esas recompensas le ofrecerán nuevas habilidades (pings, traceroutes…), que le facilitarán y/o activarán nuevos retos dentro del escenario. Con cada mini juego a demás en jugador descubrirá un trozo más de la historia y del por qué a sido abducido a la red. Escenario Minijuego 1 general

PREMIO: PREMIO: Broma o info. historia -

Minijuego 3 Minijuego 2 PREMIO: Habilidad

Arcade

Aquí se listarán todos los minijuegos existentes (línea futuro: algunos juegos estarían bloqueados, hasta no ser pasados en la historia), para que el usuario pueda escoger el que desee y pueda practicar la temática que les apetezca. A su vez en estos juegos se almacenarán algunos datos como tiempo, aciertos e intentos, que se reflejarán en una puntuación que aparecerá el apartado de Ranking (véase 3.1 Mecánicas de juego - Menú).

Ranking

A través de los resultados acaecidos en el formato Arcade, aparecen listados las 3 mejores puntuaciones por minijuego, en forma de puntos. 3.2 Mecánicas de juego

Escenario general

El jugador deberá moverse a través del escenario en la búsqueda de mini juegos. Estos se activarán en el momento que el personaje se sitúe en ciertos puntos del escenario o colisione con determinados elementos del escenario, como por ejemplo un router. Los diversos elementos que definirán el escenario y activarán los retos que serán representados por edificios (véase apartado 4.2).

El jugador podrá usar habilidades (limitadas en número y conseguidas a través de los retos), para saber qué edificios son aquellos que los activan.

Mini juegos

- Cabeceras I

Objetivo:

Ordenar en el orden correcto los diversos elementos que componen la cabecera.

Funcionamiento: Las cabeceras estarán segmentadas en bloques (que corresponderán con los componentes de la trama) y en un orden aleatorio, eso significa que que cada partida será diferente.

Bloc 1 Bloc 3 Bloc 2

El jugador mediante el cursor seleccionará uno de los bloques y lo desplazará al sitio que él escoja. Automáticamente todos los bloques se correrán una posición hacia la derecha des del punto donde se ha situado el bloque seleccionado.

Bloc 2

Bloc 1 Bloc 3 Bloc 2

El juego quedará en este estado hasta que el jugador seleccione otro elemento y repita el proceso o escoja la opción de validar, allí se le informará si es o no es correcto ese orden. En cas afirmativo enviaremos la puntuación positiva al juego general.

Bloc 1 Bloc 2 Bloc 3

Siempre tendrá la opción de abandonar el mini juego mediante la tecla “Q”

- Cabeceras II

Objetivo:

Ordenar en el orden correcto los diversos elementos que componen la cabecera, esta vez en forma de matriz.

Funcionamiento:

Las cabeceras estarán segmentadas en una matriz NxM en un orden aleatorio, en el caso que el número de fragmentos sean inferiores a la de casillas de la matriz, las últimas casillas permanecerán opacas e inseleccionables. cabecera VII cabecera V cabecera I (128 bits) (8 bits) (2 bits)

cabecera VII cabecera IV cabecera III (64 bits) (4 bits) (16 bits)

cabecera II (32 bits)

El jugador deberá seleccionar primero una casilla que quedará marcada. A continuación, marcará una segunda, y entonces ambas se intercambiarán las posiciones. Este proceso se repetirá tantas veces como considere el jugador hasta que decida validar el orden. Momento en el que recibirá el feedback.

cabecera VII cabecera V cabecera IV (128 bits) (8 bits) (4 bits)

cabecera VII cabecera I cabecera III (64 bits) (2 bits) (16 bits)

cabecera II (32 bits)

Siempre tendrá la opción de abandonar el mini juego mediante la tecla “Q”

- Binario

Objetivo:

Hacer coincidir el número en decimal con el binario.

Funcionamiento:

Se le dará al jugador un número en decimal comprendido entre 0-255, y este deberá girar los paneles activándolos [1] o desactivándolos [0] (por defecto estarán desactivados).

Para activar/desactivar se deberá disparar a los paneles para que estos giren sobre su eje. 128 64 32 16 8 4 2 1

0 0 1 0 0 0 1 0 0/1

128 64 32 16 8 4 2 1

0 0 1 0 1 0 1 0

Cuando el jugador decida validar, se le informará si es o no correcta su respuesta.

- Sincronización

Objetivo:

Seleccionar los flags en el orden correcto, para realizar la conexión en el orden correcto.

Funcionamiento:

Se le informará al jugador en que posición se encuentra (emisor/receptor). En función de su ubicación, deberá seleccionar el cubo correspondiente al flag que debe activar. Para su selección deberá disparar al cubo correspondiente.

ACK SYNC ACK 1 0 0

En caso de acertar, continúa el proceso (recibimos la respuesta a nuestro flag) y así hasta que se acaba el proceso. En caso de fallar, se nos informa de nuestro error y se acabará la partida.

3.3 User Interface

Escenario general

Movimientos Teclas Interacciones Mouse Adelante W Movimiento Cámara Movimiento Izquierda A Acción/Disparo Botón Principal Atrás S - Botón Secundario Derecha D Salto SPACE

Acción Q Ítems NUMBERS

Cabeceras I y II

Movimientos Teclas Adelante W/UP Izquierda A/LEFT Atrás S/DOWN Derecha D/RIGHT Seleccionar SPACE

Validar ENTER Salir Q Ayuda H

Binario y Sincronización

Movimientos Teclas Interacciones Mouse Validar ENTER Movimiento Cámara Movimiento Salir Q Acción/Disparo Botón Principal Ayuda H - Botón Secundario

4. Art Work:

4.1 Moodboard

4.2 Diseño escenarios

4.2 Diseño personajes

Protagonista:

- Estudiante del Campus La Salle Barcelona en el mundo virtual

Vista general Vista FPS 4.4 Paleta de colores

Paleta Tron Paleta Matrix Paleta Orange Box

4.4 GUI

Fuentes:

- Courier New - Arial

5. Audio:

5.1 Escenario principal:

Ambientación:

Canciones : Al principio músicas de fondo un poco estresantes y oscuras al estilo “Crysis 2” o “Batman: Arkhan City”. Estas melodías transmiten alta incertidumbre e inseguridad (siguiendo paralelamente las sensaciones de un alumno al empezar a estudiar algo nuevo). A medida que el usuario vaya pasando retos, el estilo musical se irá clareando hacia temas apaciguadores e incluso alegres pero sin perder algo de incertidumbre, como por ejemplo vemos en bandas sonoras de videojuegos como “Hitman 2”, “Borderlands”, y la mayoría MMO.

Paisaje/Envolvente: Todas las melodías irán acompañadas por efectos futuristas como por ejemplo el zumbido de una valla electrificada, el disparo de una nave espacial, ruidos de robots (R2-D2)… Y algunos loops de “Drum and Bass” para darle el toque estresante, sobretodo al principio.

Eventos:

Guis: Sonido de burbuja que explota cuando aparece y desaparece. Si el texto de dentro va apareciendo secuencialmente, se asocia un sonido de tecleo. Otra posibilidad es que los textos sean reproducidos a través de una voz.

Personaje principal:

a) Movimientos:

- Salto: Sonido de impacto al caer. - Andar: Ruido de pisadas del personaje dependiendo del terreno que pisa. - Disparo: Ruido de disparo. - Llegada a punto de activación (Boton Q) de minijuego: Diferentes tipos de voces: “oh oh”, “OUCH”, “WTF”… -Cambiar items (botones numbers): Sonido depende del tipo de item. b) Voz:

- De vez en cuando el personaje dice alguna frase como: “¿Y ahora qué?”, “¿A dónde voy?”, “Tengo hambre”… -Llegada a punto de activación (Boton Q) de minijuego: Diferentes tipos de voces: “oh oh”, “OUCH”, “WTF”…

5.2 Minijuegos:

Todos los minijuegos tendrán:

- Gui: Sonido de mini explosión, o algo similar al aparecer o desaparecer algún cuadro de diálogo explicativo. - Música de 8 bits: canciones de videojuegos retro tipo Mario Bros, Sonic, Megaman. - Victoria: Melodía de victoria siguiendo el patrón de juegos antiguos. - Derrota: Melodía de derrota siguiendo el patrón de juegos antiguos.

- Cabeceras I

Eventos: a) Sonido 1 al seleccionar bloque. b) Sonido 2 al dejar bloque seleccionado donde estaba. c) Sonido 3 al dejar bloque seleccionado en otra posición correcta. d) Sonido 4 asignado al aumento de puntuación. e) Sonido 5 al seleccionar una posición errónea donde dejar el bloque. f) Sonido 6 al desplazar bloques a la derecha. g) Sonido 7 al apretar letra Q para salir del minijuego.

- Cabeceras II

Eventos: a) Sonido 1 al seleccionar bloque. b) Sonido 2 al seleccionar el segundo bloque a intercambiar. c) Sonido 3 al hacer el intercambio de bloques. d) Sonido 4 asignado al click de validación del jugador cuando crea tener todos los bloques en orden. e) Sonido 5 al apretar letra Q para salir del minijuego.

- Binario

Eventos: a) Sonido 1 al disparar. b) Sonido 2 al impactar con panel. c) Sonido 3 al girarse el panel. d) Sonido 4 al clicar para validar. e) Melodía de derrota al validar cuando el número es incorrecto.

- Sincronización:

Eventos: a) Sonido 1 al disparar. b) Sonido 2 al impactar con panel. c) Sonido 3 al dar en el panel adecuado. d) Melodía de derrota al dar en panel incorrecto. 5.3 Transiciones:

Al pasar del escenario principal a un minijuego o viceversa aparecerá un efecto (pitido amortiguado o similar), que indica un cambio escenario.

5.4 Menú:

Una melodía igual que en apartado de ambientación del Escenario principal, con sonido futuristas (paso de electricidad, robot R2-D2… ).