Post on 06-Apr-2016
description
VideojocsCREACIÓ I DESENVOLUPAMENT
TREBALL DE RECERCA
Dirigit per Juliette VillanuevaNovembre 2014
Pau Montull i JovéI n s t i t u t Montserrat
Agraïments
El meu agraïment més sincer per Juliette Villanueva, per la seva
paciència i per guiar-me i ajudar-me en tots el moments en que ho he
necessitat. Vull agrair, també, el suport de tots els qui m’han
acompanyat en l’odissea que ha suposat aquest Treball de Recerca.
Amb ells he compartit nervis, dubtes i inquietuds. Gràcies, per tant, als
meus familiars i amics més propers.
Índex
1 Introducció ............................................................................................................................................8
2 procés de Desenvolupament d’un videojoc ................................................................................ 10
2.1 Introducció ..................................................................................................................................... 11
2.2 Fase de pre-producció ................................................................................................................. 12
2.2.1 El document de disseny del joc .......................................................................................... 12
2.2.1.1 Alt concepte ................................................................................................................... 13
2.2.1.2 Gènere ............................................................................................................................ 13
2.2.1.3 Jugabilitat bàsica .......................................................................................................... 13
2.2.1.4 El diagrama de controlador ........................................................................................ 13
2.2.1.5 La interfície d’usuari durant el joc .............................................................................. 14
2.2.1.6 Menús i interfície gràfica principal ............................................................................. 14
2.2.1.7 Menús contextuals ....................................................................................................... 14
2.2.1.8 Gestió i balanç de les mecàniques de joc ................................................................. 14
2.2.1.9 Entorn ............................................................................................................................. 15
2.2.1.10 Personatges ................................................................................................................ 15
2.2.1.11 Descripció d’escenes cinematogràfiques .............................................................. 15
2.2.1.12 Disseny de nivells, missions i àrees ........................................................................ 15
2.2.1.13 Sprites bidimensionals i models tridimensionals................................................. 16
2.2.1.14 Missions, nivells i àrees ............................................................................................. 16
2.2.1.15 Doblatge ...................................................................................................................... 16
2.2.1.16 Música ........................................................................................................................... 16
2.2.2 Document de disseny tècnic ............................................................................................... 17
2.2.2.1 Definició de les fites ..................................................................................................... 17
2.2.2.2 Metodologia de desenvolupament ........................................................................... 17
2.2.2.3 Anàlisi i elecció del motor de joc ................................................................................ 19
2.2.2.4 Anàlisi i elecció de programari artístic ...................................................................... 19
2.3 Fase de producció ......................................................................................................................... 19
2.4 Fase de post-producció ............................................................................................................... 19
3 Desenvolupament Pràctic .............................................................................................................. 20
3.1 Introducció ..................................................................................................................................... 21
3.2 Anàlisi de programari ................................................................................................................... 21
3.2.1 Anàlisi de motor de joc: “Unity Free” ................................................................................. 21
3.2.1.1 Gestió de recursos de joc ............................................................................................ 21
3.2.1.2 Gestió de l’espai virtual tridimensional .................................................................... 22
3.2.1.3 Interfície d’usuari .......................................................................................................... 22
3.2.1.4 Plataformes ................................................................................................................... 25
3.2.1.5 Programació .................................................................................................................. 26
3.2.1.6 Animació ......................................................................................................................... 26
3.2.1.7 Renderització ................................................................................................................. 28
3.2.1.8 Efectes especials .......................................................................................................... 29
3.2.1.9 Il·luminació ..................................................................................................................... 29
3.2.1.10 Àudio ............................................................................................................................. 29
3.2.1.11 Física ............................................................................................................................. 29
3.2.2 Anàlisi de motor de joc: “UDK” ........................................................................................... 30
3.2.2.1 Gestió de recursos de joc ............................................................................................ 30
3.2.2.2 Gestió de l’espai virtual tridimensional .................................................................... 30
3.2.2.3 Interfície d’usuari .......................................................................................................... 30
3.2.2.4 Plataformes ................................................................................................................... 32
3.2.2.5 Programació .................................................................................................................. 32
3.2.2.6 Animació ......................................................................................................................... 32
3.2.2.7 Renderització ................................................................................................................. 32
3.2.2.8 Il·luminació ..................................................................................................................... 32
3.2.2.9 Àudio ............................................................................................................................... 33
3.2.2.10 Física ............................................................................................................................. 33
3.2.3 Autodesk Maya ...................................................................................................................... 33
3.2.3.1 Interfície d’usuari .......................................................................................................... 33
3.2.3.2 Modelatge ...................................................................................................................... 35
3.2.3.3 Animació ......................................................................................................................... 35
3.2.3.4 Textures i materials ..................................................................................................... 36
3.2.4 Autodesk Mudbox ................................................................................................................. 36
3.2.4.1 Escultura tridimensional ............................................................................................. 36
3.2.4.2 Topologia ....................................................................................................................... 37
3.2.4.3 Interoperabilitat amb Maya ........................................................................................ 37
3.2.4.4 Interfície d’usuari .......................................................................................................... 37
3.3 Fase de pre-producció ................................................................................................................. 39
3.3.1 Document de disseny del joc .............................................................................................. 39
3.3.1.1 Alt concepte ................................................................................................................... 39
3.3.1.2 Gènere ............................................................................................................................ 39
3.3.1.3 Jugabilitat bàsica .......................................................................................................... 40
3.3.1.4 El diagrama de controlador ........................................................................................ 41
3.3.1.5 La interfície d’usuari durant el joc .............................................................................. 41
3.3.1.6 Menús i interfície gràfica principal ............................................................................. 41
3.3.1.7 Gestió i balanç de les mecàniques de joc ................................................................. 44
3.3.1.8 Entorn ............................................................................................................................. 45
3.3.1.9 Personatges .................................................................................................................. 45
3.3.1.10 Disseny de nivells, missions i àrees ........................................................................ 45
3.3.2 Document de Disseny Tècnic ............................................................................................. 46
3.3.2.1 Metodologia de desenvolupament ........................................................................... 46
3.3.3 Comparació analítica dels motors de joc estudiats........................................................ 47
3.3.3.1 Anàlisi i elecció del motor de joc ................................................................................ 49
3.3.3.2 Anàlisi i elecció de programari artístic ...................................................................... 49
3.4 Producció ....................................................................................................................................... 49
3.4.1 Desglossament de les tasques en mòduls ...................................................................... 49
3.4.2 Entorn de desenvolupament iteratiu ................................................................................ 50
3.4.3 Nivell 1 .................................................................................................................................... 52
3.4.3.1 Mecànica de moviment bàsic del jugador ................................................................ 52
3.4.3.2 Mecànica dels canvis de direcció i sentit de la gravetat ........................................ 57
3.4.3.3 Mecànica de ganxo extensible ................................................................................... 66
3.4.4 Nivell 2 .................................................................................................................................... 71
3.4.4.1 Mecànica d’esprints i millores del controlador del personatge ........................... 71
3.4.4.2 Mecànica de gestió del reinici del nivell .................................................................... 72
3.4.4.3 Models de la pistola de gravitons i el dispositiu de ganxo extensible ................ 73
3.4.5 Nivell 3 .................................................................................................................................... 74
3.4.5.1 Entorn gràfic del primer nivell del joc ....................................................................... 74
3.4.5.2 Creació del sistema de menús ................................................................................... 77
4 Conclusions ....................................................................................................................................... 82
5 Fonts Consultades ........................................................................................................................... 84
6 Annexos ............................................................................................................................................. 87
6.1 Annex 1: Glossari tècnic............................................................................................................... 88
6.2 Annex 2: Programes complets ................................................................................................... 90
6.2.1 RigidbodyFPSWalker ............................................................................................................ 91
6.2.2 Controlador de personatge (capsuleController) ............................................................. 92
6.2.3 Mecànica de ganxo extensible (grapplingShot) .............................................................. 96
6.2.4 Mecànica de canvis de gravetat (gravityTarget) ............................................................. 97
6.2.5 Mapa d’animacions de cada menú (Menu) ....................................................................... 98
6.2.6 Transicions entre Menús (menuManager) ....................................................................... 99
6.2.7 Canvis de qualitat del joc (QualityControl) ..................................................................... 100
6.2.8 Canvis de volum del joc (VolumeControl) ...................................................................... 100
6.2.9 Indicador numèric del botó de desplaçament del volum (VolumeMeter)................ 101
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 8/101 Pau Montull i Jové
1 INTRODUCCIÓ
L’objectiu principal d’aquest treball de recerca sobre els videojocs és investigar les
possibilitats que té una persona amb els meus recursos i coneixements -com a estudiant de
batxillerat- per desenvolupar un videojoc funcional.
He escollit un tema relacionat amb els videojocs perquè personalment m’interessen molt i
perquè crec que, tot i el creixement gairebé exponencial de la seva presencia en la societat
occidental, la indústria dels videojocs (que actualment mou quantitats immenses de diners i
ofereix un servei a milions de persones) no es té prou en compte a nivell tècnic.
Els avenços tecnològics i també conceptuals sobre la manera d’entendre aquests continguts
interactius que anomenem videojocs han acostat la producció d’aquests a un sector menys
comercial que no disposa dels medis econòmics o no té el rerefons tècnic necessari per
desenvolupar videojocs per les vies tradicionals. L’aparició d’aquest sector, exitós i cada cop
més gran, de desenvolupadors amateurs o independents que es centren més en el contingut
dels videojocs que en els beneficis econòmics que en poden treure m’ha portat a plantejar-
me si una persona com jo podria fer un videojoc i com podria fer-ho.
El treball està dividit en dos grans blocs; el primer és l’estudi teòric del procés de
desenvolupament de videojocs i el segon és el marc pràctic específic per al desenvolupament
d’un videojoc creat per mi. En el primer bloc, per tant, s’estudien els elements bàsics comuns
a qualsevol procés de desenvolupament d’un videojoc. A la part pràctica, en canvi, s’aplica la
teoria de desenvolupament del bloc anterior a la creació d’un videojoc funcional.
Les limitacions del marc pràctic són evidents; el temps de desenvolupament, els recursos als
quals jo pugui accedir i els coneixements que pugui adquirir durant l’elaboració del treball
restringiran les meves possibilitats per desenvolupar el videojoc. Ja que el temps de
desenvolupament d’un videojoc acostuma a rondar un any, no s’esperarà un videojoc
complet en estat de distribució com a resultat del bloc pràctic. No obstant això, el fet de
desenvolupar un videojoc individualment1 i la meva capacitat per aprendre el mètode i la
1 Tradicionalment els videojocs es desenvolupen en equips multidisciplinaris on es reparteixen les tasques als membres de l’equip que en siguin experts.
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 9/101 Pau Montull i Jové
tècnica de desenvolupament estan inclosos dins de l’objectiu principal, i per tant es valoraran
a partir de l’estat final del videojoc.
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 10/101 Pau Montull i Jové
2 PROCÉS DE
DESENVOLUPAMENT D’UN
VIDEOJOC
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 11/101 Pau Montull i Jové
2.1 Introducció
El desenvolupament de videojocs és un procés de creació de programari informàtic.
El fet que la del videojoc sigui una indústria relativament nova, però sobretot, innovadora i
constantment canviant, potencia la varietat de metodologies i maneres d’afrontar aquest
procés.
No obstant aquesta varietat, tant en la indústria anomenada “indie” com en la més comercial,
es mantenen unes fases de desenvolupament més o menys definides i que s’emfatitzen més
o menys a la pràctica. Anomenades de maneres diferents a vegades, sempre són tres: la Pre-
Producció, la Producció i la Post-Producció i un videojoc mai es pot considerar acabat si no
ha passat per les tres.
Per a poder aprofundir bé en els detalls del desenvolupament de videojocs he decidit acotar
la meva recerca i investigar com algú com jo, un estudiant de batxillerat sense cap
experiència en aquest camp fins el moment, podria fer un videojoc.
Així, en aquest bloc teòric s’exposarà la recerca de processos i eines al meu abast que faré
servir més endavant en la part pràctica del treball, que serà el desenvolupament d’un joc
completament funcional.
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 12/101 Pau Montull i Jové
2.2 Fase de pre-producció
La de pre-producció, o de disseny, és la primera fase en la línia de desenvolupament d’un
videojoc.
És una fase de planificació de projecte enfocada al desenvolupament conceptual i de
documents de disseny inicials.
L’objectiu principal d’aquesta fase és obtenir una documentació abundant, precisa i fàcilment
intel·ligible que descrigui el videojoc que es vol obtenir i les seves característiques, així com
els procediments i l’ordre en que es duran a terme en la següent fase. Aquesta informació
es recull bàsicament en tres grans documents que són el Document de Disseny del Joc o
GDD2, el Document de Disseny Artístic o ADD3 i el Document de Disseny Tècnic o TDD4.
2.2.1 EL DOCUMENT DE DISSENY DEL JOC
El GDD es centra directament en el videojoc. Els seus apartats descriuen detalladament la
majoria d’aspectes del videojoc en sí, com la disposició dels menús i les interfícies gràfiques
del joc, l’aspecte més narratiu (la història, la posada en escena, els detalls dels personatges)
o les mecàniques del joc.
La primera part del GDD definirà breu i generalment el producte final que es vol obtenir del
procés de desenvolupament del joc. Seguidament es consolida el què farà en cada moment
el jugador, emfatitzant les peculiaritats del joc respecte els altres jocs del mateix gènere. En
els següents apartats del GDD es detalla totes les mecàniques de joc que no controli
directament el jugador durant el joc (p. ex. Un sistema de millores de personatges). I els
últims apartats del GDD són llistes d’objectes de joc i altres recursos utilitzats.
2 GDD: De l’anglès Game Design Document. 3 ADD: De l’anglès Art Design Document. 4 TDD: De l’anglès Technical Design Document.
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 13/101 Pau Montull i Jové
2.2.1.1 Alt concepte
Alt concepte5 es refereix a la breu descripció (no més d’un paràgraf) dels aspectes principals
del videojoc que es pretén desenvolupar. Idealment s’ha de descriure unes idees prou
generals, clares i entenedores en aquest document perquè no hagin de canviar en cap punt
del procés de desenvolupament i sempre es pugui adreçar-s’hi per tenir una idea de quin és
el resultat que s’espera del videojoc.
Normalment l’alt concepte inclou l’estil del joc, la temàtica, el gènere, el disseny, aspectes
de la jugabilitat com el posicionament de la càmera, les motivacions del jugador per a jugar,
si es desenvolupa en dues o tres dimensions, per a quina o quines plataformes es
desenvoluparà, el maquinari controlador que es necessitarà per a jugar i altres detalls
essencials per a comprendre la mecànica de joc.
2.2.1.2 Gènere
Aquí es concreta més específicament el gènere del joc i les influències o els elements d’altres
gèneres que pot tenir.
2.2.1.3 Jugabilitat bàsica
En aquest apartat s’estableix la interacció del jugador amb el joc durant el joc i es concreta
quines mecàniques de joc haurà de fer servir.
2.2.1.4 El diagrama de controlador
Per a poder tenir una millor idea de la jugabilitat, és molt convenient crear un diagrama dels
controladors de maquinari perifèric que permetran la interacció del jugador. El diagrama ha
de relacionar clarament cadascuna de les entrades del controlador (ja siguin botons o altres
sensors com potenciòmetres, acceleròmetres...) amb les funcions que desenvolupa al joc.
5 Alt Concepte: De l’anglès High-Concept.
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 14/101 Pau Montull i Jové
2.2.1.5 La interfície d’usuari durant el joc
En aquest apartat s’inclou diversos diagrames de la interfície gràfica que veurà l’usuari
mentre jugui. Conformen la interfície d’usuari, i per tant s’hauran de definir, tots els elements
gràfics que no formen part de l’entorn però es mantenen constantment a la pantalla per a
proporcionar informació al jugador (p. ex. Un element que marca el centre de la pantalla per
a que el jugador sàpiga exactament cap a on està apuntant).
2.2.1.6 Menús i interfície gràfica principal
Aquí es descriu la interfície Gràfica d’inici i els diversos menús inicials com el menú d’opcions
o el de partides guardades. Es completen els esquemes amb anotacions i diagrames de
navegació que determinin un ordre de navegació entre els menús. També s’hi descriuen
detalls com la gamma de colors, l’estil gràfic dels menús o fins i tot les animacions de
transició entre menús.
2.2.1.7 Menús contextuals
Aquest apartat es refereix a totes les mecàniques que, per la seva complexitat o per a facilitar
la seva gestió per part del jugador, requereixen un menú o interfície específic. S’hi inclouen
diagrames de navegació i nexes entre menús i esquemes de les diferents interfícies
gràfiques.
2.2.1.8 Gestió i balanç de les mecàniques de joc
Aquí s’han d’especificar els detalls de les mecàniques de joc, des de la velocitat del moviment
del jugador fins al valor de les millores i els articles de joc en el cas que n’hi hagi. Aquest
apartat s’emplena de taules de valors, diagrames i gràfics que estableixen els detalls dels
diversos elements del joc.
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 15/101 Pau Montull i Jové
La majoria de videojocs, fins i tot els més senzills, contenen una narració; una història que
permet als jugadors involucrar-se i assimilar un objectiu. En aquesta secció del GDD
s’elaboren l’espai i el temps narratius (el món on es desenvolupa el joc), els diferents
personatges i la història més o menys lineal que portarà el jugador des del principi fins al
final del joc.
2.2.1.9 Entorn
En aquest apartat es descriu l’espai i el temps narratius detalladament. S’hi detalla tot allò
rellevant pel joc o per la comprensió de la història del joc. Sovint s’hi adjunten il·lustracions
dels escenaris i de mapes del món del videojoc.
2.2.1.10 Personatges
Aquí es descriuen els diferents personatges i els seus atributs i diferències. Normalment
s’especifica de cada personatge quin tipus personatge és, on el podem trobar dins del joc i
les diferents mecàniques de joc que té. També s’acostuma a acompanyar amb il·lustracions
de cada personatge.
2.2.1.11 Descripció d’escenes cinematogràfiques
En el cas que el joc utilitzi escenes cinematogràfiques com a recurs narratiu es descriuran en
aquest apartat. Normalment les escenes cinematogràfiques es representen en forma de
guió il·lustrat.
2.2.1.12 Disseny de nivells, missions i àrees
En aquest apartat, i basant-se en el guió, es dóna una descripció exhaustiva acompanyada
d’il·lustracions dels diferents nivells del joc. Es descriu la forma, els colors, l’ambient, etc... de
l’entorn i s’estableix l’ordre causal de les missions mitjançant esquemes i diagrames.
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 16/101 Pau Montull i Jové
2.2.1.13 Sprites bidimensionals i models tridimensionals
Llistat de Models i Sprites necessaris amb els seus atributs adjunts llistats per l’ordre
d’aparició en el joc.
2.2.1.14 Missions, nivells i àrees
Tot i que a la secció anterior ja s’han descrit aquests aspectes del joc, ara es duu a terme una
llista enfocada als objectes de joc que els conformaran. De manera que s’hi detallen aspectes
més tècnics com les mides, la prioritat o el posicionament jeràrquic dins del motor de joc.
2.2.1.15 Doblatge
Aquí es llisten les gravacions necessàries per al doblatge dels personatges del videojoc en
forma de guió.
2.2.1.16 Música
En aquest apartat s’inclou la música que s’inclourà al joc (si és que n’hi ha) i altres aspectes
tècnics com els efectes de transició entre pistes.
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 17/101 Pau Montull i Jové
2.2.2 DOCUMENT DE DISSENY TÈCNIC
El TDD està enfocat al pla de desenvolupament del videojoc, i és per això que defineix les
eines i els mitjans per a dur-lo a terme.
La primera secció del TDD conté els detalls del procés de desenvolupament en si:
2.2.2.1 Definició de les fites
Aquesta secció és el calendari del pla de desenvolupament: aquí es marca els estats
intermedis de desenvolupament en que s’ha de trobar el videojoc en unes certes dates. Així
es podria definir, per exemple, una fita per tenir una versió de demostració tècnica, una altra
per un videojoc funcional, una altra per un videojoc en estat de publicació alfa6, etcètera.
2.2.2.2 Metodologia de desenvolupament
En aquest apartat queda concretada la metodologia que es farà servir per desenvolupar el
videojoc. S’hi ha de precisar el repartiment de les tasques entre els membres de l’equip de
desenvolupament.
La metodologia de producció de programari aplicada a la creació de videojocs més feta servir
és la de desenvolupament en cascada (Wikipedia, Waterfall model, 2014). En aquest procés
6 S’anomena estat alfa, a l’estat de desenvolupament d’un videojoc en que aquest es pot publicar com a tal però encara no està acabat. El següent estat abans de la publicació oficial s’anomena beta i el canvi d’alfa a beta s’acostuma a definir pel moment en que el joc té tots els recursos artístics implementats.
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 18/101 Pau Montull i Jové
de disseny seqüencial clàssic el progrés flueix constantment cap avall (com una cascada) a
través de les fases de requeriments, disseny, implementació, verificació i manteniment.
Fig. 2.2.1 : Metodologia de desenvolupament en cascada
Tot i que la de desenvolupament en cascada ha estat i encara és un procés efectiu i respectat
en l’àmbit de la producció de software, s’han de tenir en compte les seves òbvies limitacions.
La més evident recau, paradoxalment, en el principi bàsic del procés: no es pot progressar
sempre cap a baix sense pujar a vegades. En una situació real és sinó impossible, gairebé,
definir tots els requeriments a la primera fase i progressar cap avall des d’aquí, en canvi, les
complicacions o modificacions que es trobin en qualsevol fase poden obligar a retrocedir els
desenvolupadors per a una bona implementació. Per a solucionar aquest problema hi ha dos
enfocaments populars: l’un és modificar lleugerament el procés en cascada per afegir fases
com la de proves o la d’anàlisi, i l’altra solució es utilitzar una metodologia més iterativa com
la de desenvolupament àgil.
La metodologia de desenvolupament àgil de programari és aquella en la qual els
requeriments i les solucions evolucionen a través de la col·laboració entre equips
multidisciplinaris (Wikipedia, Agile software development, 2014). En aquest procés es
promou la planificació adaptativa, el desenvolupament evolutiu i la resposta ràpida i flexible
als canvis (Beck, et al., 2001).
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 19/101 Pau Montull i Jové
2.2.2.3 Anàlisi i elecció del motor de joc
Com ja s’ha explicat en el Bloc 1, podem considerar el motor de videojoc com el programari
intermediari entre el sistema operatiu i el joc i sobre el qual es construeix aquest. Per la
importància d’aquest element en el desenvolupament del joc, es dedica la següent part del
TDD a fer-ne la elecció.
2.2.2.4 Anàlisi i elecció de programari artístic
De la mateixa manera que l’anterior, aquest apartat està dedicat a la tria de programari. S’hi
justifica la elecció de programari artístic bidimensional o tridimensional.
2.3 Fase de producció
Durant la fase de producció és posa en pràctica el procés planificat en la fase de pre-
producció i que consta als documents de disseny (al GDD i al TDD). L’objectiu d’aquesta fase
és aconseguir un videojoc funcional i acabat mitjançant la metodologia de desenvolupament
del TDD i amb les dates d’assoliment de fites que s’especifiquen en aquest.
2.4 Fase de post-producció
En aquesta fase es gestiona tot el que té a veure directament amb l’ús final del joc acabat: el
màrqueting, la gestió de la venta i distribució del producte, el servei tècnic...
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 20/101 Pau Montull i Jové
3 DESENVOLUPAMENT PRÀCTIC
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 21/101 Pau Montull i Jové
3.1 Introducció
En aquest bloc del treball posaré en pràctica tota la teoria del procés de desenvolupament
d’un videojoc vista al bloc anterior per desenvolupar el meu propi videojoc. Passaré per les
fases de pre-producció i producció, però com que tinc un temps molt limitat, no espero acabar
la producció del joc, i per tant, no arribaré tampoc a la fase de post-producció.
3.2 Anàlisi de programari
Per a l’elaboració del document tècnic de joc he realitzat una comparació de diferents
programes i motors de joc per escollir els que faré servir, a la fase de producció, per
desenvolupar el videojoc.
3.2.1 ANÀLISI DE MOTOR DE JOC: “UNITY FREE”
“Unity és un motor de desenvolupament completament integrat i amb nombroses funcions
que proporciona funcionalitat immediata per a la creació de contingut bidimensional i
tridimensional interactiu.”
3.2.1.1 Gestió de recursos de joc
Tots els elements que apareixen individualment en una escena de Unity són Objectes de Joc,
o “GameObjects”, en anglès; són objectes virtuals diferenciats entre sí pels components que
contenen. Per aquesta raó podem dir que l’objecte de joc és a Unity el bloc bàsic de la
construcció d’escenes: tots els objectes de joc són pràcticament iguals entre ells al principi, i
són els components que els afegim el què els diferencia i els atribueix les característiques.
Tots els objectes de joc tenen com a mínim el component de “transformació”, que els aporta
una posició a l’escena, una rotació i una mida o escala. A més a més, són components utilitzats
freqüentment el de “càmera”, el de “llum”, el receptor d’àudio, l’emissor d’àudio, el de cos rígid,
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 22/101 Pau Montull i Jové
el de caixa de cel, el de “reflex de lent”, el de “renderitzador de malla”, els “col·lisionadors”, el
d’”animador”, el de “programa”, etc...
Aquesta gestió dels recursos permet una gran
versatilitat per crear objectes de joc molt
específics i complexos i és alhora entenedora,
gràfica i fàcil de fer servir.
3.2.1.2 Gestió de l’espai virtual tridimensional
Unity fa servir malles tridimensionals i no permet grans quantitats de modelatge
tridimensional a l’editor, ja que tot i proporcionar formes primitives (cubs, esferes, anells
toroïdals, etc.) per afegir a l’escena, no està preparat per fer-ne modificacions extenses a la
forma. Per aquesta raó és necessari un programa extern per la creació de models
tridimensionals elaborats.
3.2.1.3 Interfície d’usuari
La interfície d’usuari de Unity és senzilla, clara, expansible i fàcil de personalitzar. Consta de
cinc finestres tabulades anomenades vistes que podrem organitzar com ens sigui més útil.
Aquestes finestres són la vista d’escena, la vista de joc, la vista de projecte, la vista de jerarquia
i la vista d’inspector.
Fig. 3.2.1 : Components d'un objecte de joc a la vista d'inspector de Unity: de dalt a baix component de
transformació, càpsula, renderitzador de malla, col·lisionador de càpsula, cos rígid, dos arxius de
programa escrits l'un en javascript i l'altre en C# i renderitzador de materials.
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 23/101 Pau Montull i Jové
Fig. 3.2.2: Interfície d'usuari de Unity
La vista d’escena, que és una vista tridimensional de l’escena de joc, ens permet construir
visualment el joc. Aquí s’hi representaran tots els objectes de joc de l’escena. El mode de
renderitzat de la vista d’escena es pot canviar segons si mostra textures o la gamma de colors.
També es pot activar o desactivar des d’aquesta vista les opcions de 3D, els efectes com la
Caixa de cel o els reflexos de càmera, les llums i els sons de l’escena. Es pot canviar entre la
perspectiva tridimensional, la isomètrica i la vista bidimensional a través del gizmo situat a la
cantonada superior dreta de la vista. Finalment, hi ha un menú anomenat Gizmos, on podrem
controlar quins d’aquests elements vectorials surten a la vista d’escena.
La vista d’escena és completament interactiva i hi podrem seleccionar i posicionar qualsevol
objecte de joc que hi hagi a l’escena de forma gràfica mitjançant les eines de trasllat, rotació i
escalat i els seus gizmos respectius.
La càmera de la vista d’escena és externa al joc i només es pot controlar mitjançant les eines
de navegació del programa.
La vista de joc és el que s’anomena una visualització “WYSIWYG” (acrònim de la frase anglesa
“What You See Is What You Get”: el que veus és el que obtens), per tant, la vista de joc ens
permetrà veure en qualsevol moment una previsualització fidedigna de l’estat del producte
ESCENA
INSPECTOR
JERARQUÍA
PROJECTE
JOC
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 24/101 Pau Montull i Jové
que s’està desenvolupant. Com en el joc final, i a diferència de la vista d’escena, la vista de joc
només podrà mostrar imatges renderitzades des d’un objecte de joc amb un component de
càmera i que sigui a l’escena.
A sobre d’aquesta vista hi ha el menú de reproducció. El menú de reproducció consta de tres
botons; “reproduir”, “posar en pausa” i “avançar fotograma” que controlen la reproducció de
la previsualització del joc. En clicar “reproduir” entrem en el mode de previsualització i tot
excepte la vista de joc s’ennegreix. Si modifiquem algun paràmetre de l’escena dins del mode
de previsualització només es mantindrà durant la previsualització, proporcionant-nos així una
manera de fer canvis i provatures sobre la marxa sense modificar realment la feina feta.
Aquesta característica és molt útil per a fer canvis que afecten la jugabilitat, ja que el resultat
n’és instantani i es pot veure mentre es juga, però s’ha de tenir en compte que si els volem
mantenir els haurem de recordar i tornar a fer un cop fora de la previsualització. El botó “posar
en pausa” del menú de reproducció interromp la previsualització sense sortir d’aquest mode,
i permet avançar fotograma a fotograma amb l’últim botó del menú: el botó “avançar
fotograma”.
La vista de joc conté tres menús: el primer, situat a l’extrem superior esquerre de la vista,
serveix per a canviar la relació d’aspecte de la previsualització. El següent menú d’esquerra a
dreta és el de maximitzar en reproduir, que com indica el seu nom, si està activat quan
reproduïm una previsualització de l’escena, maximitza la vista de joc, que passa a ocupar tot
l’espai de l’editor. La vista maximitzada és molt útil per a provar el joc des del punt de vista del
jugador, ja que és tot el que hi veurà, però el fet que ompli l’espai de l’editor impedeix la
elaboració de canvis a temps real. Seguidament hi ha un menú per a permetre’ns visualitzar
diferents estadístiques sobre el rendiment del joc en plena previsualització. El menú superior
dret d’aquesta vista és el dels gizmos, que ens permet activar o desactivar la visibilitat dels
diferents gizmos a la vista de joc per a donar-nos una millor visió de com estan interaccionant
realment els diferents components i objectes de joc. A diferència de la vista d’escena, a la vista
de joc no podem interaccionar directament amb els objectes que hi apareixen.
Des de la vista de projecte podem accedir i gestionar els recursos digitals del nostre projecte.
L’esquerra de la vista mostra l’estructura de carpetes en forma de llista jeràrquica, i a la dreta
hi podem veure tots els elements de la carpeta seleccionada amb les seves respectives icones
o imatges de mostra. A sobre la carpeta de recursos hi ha una llista de preferits on
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 25/101 Pau Montull i Jové
s’emmagatzemen automàticament els recursos que es facin servir de forma més freqüent. Al
menú superior de la vista de projecte hi trobem una barra de cerca amb les opcions de cercar
segons el tipus d’arxiu o segons les etiquetes i la de guardar la cerca com una carpeta de
preferits.
La vista de jerarquia ens mostra la llista jeràrquica de tots els Objectes de joc que hi ha a cada
moment a l’escena.
Unity fa servir un concepte anomenat “parenting”. Per a convertir un objecte de joc en fill d’un
altre, s’arrossega l’un a sobre de l’altre. Un fill heretarà el moviment i la rotació del seu pare.
Sempre que es mou o es rota l’objecte pare a l’editor, el fill el seguirà, i moure l’objecte fill a
l’editor només li canviarà la posició relativa respecte el pare. De manera que si per exemple
situem una càmera a l’alçada dels ulls d’un personatge animat i després la convertim en filla
de l’objecte del personatge, aquesta el seguirà mantenint la seva posició relativa; fixada al seu
moviment i la seva rotació.
La vista d’inspector ens mostra detalladament la informació de l’objecte de joc seleccionat i
ens en permet modificar tots els paràmetres.
A la part superior del panell hi ha el nom de l’objecte seleccionat, el botó per a desactivar-lo,
el botó “estàtic” que fa entendre al motor de joc que aquest objecte no es mourà, i per tant no
fa falta que en calculi la geometria constantment. També hi trobem el menú d’etiquetes, que
agrupa l’objecte segons la seva funció i el menú de capes que situa l’objecte en una capa de
renderitzat. Es pot afegir i modificar tant capes com etiquetes segons sigui convinent.
A sota d’aquests menús principals hi ha els components de l’objecte, que com ja s’ha explicat,
determinen les seves propietats.
3.2.1.4 Plataformes
El motor de desenvolupament Unity està disponible per als sistemes operatius Windows i OS
X, i permet la creació de videojocs per a aquests dos i, a més a més, Linux, iOS, Android,
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 26/101 Pau Montull i Jové
Windows Phone 8, BlackBerry 10, Xbox 360, Playstation 3, Playstation Vita, Wii, Wii U i per a
l’extensió d’explorador web “Unity Web Player”.
3.2.1.5 Programació
Unity conté tres diferents possibilitats pel que fa a llenguatges de programació: no només
podem programar en javascript, C# i Boo, sinó que a més a més els podem combinar.
Unity proporciona també un programa per a la escriptura de programes anomenat
“Monodevelop”, que incorpora la API (en anglès, Application Programming Interface, interfície
de programació d’aplicacions) de Unity. Aquesta API ens proporciona variables i funcions
específiques per a la creació de programes complexos i interactius amb els diferents
components i objectes de joc.
3.2.1.6 Animació
El motor d’animacions de Unity s’anomena “Mecanim”, i està completament integrat al
programa.
Com la majoria d’eines de Unity, Mecanim està preparada per a interaccionar amb els
programes del nostre joc; així, una animació pot executar una funció de dins el programa de
l’objecte animat i una variable d’un programa pot desencadenar una animació.
Qualsevol Objecte de Joc és animable a través de Mecanim, des de simples línies vectorials
(anomenades “sprites” en anglès) fins a la intensitat d’una llum de l’escena o un personatge
amb articulacions complexes. Aquest motor d’animació és capaç d’interpretar mapes
d’articulacions (més coneguts com a “rigs”) generats i importats d’altres programes de disseny
tridimensional.
Mecanim té dues maneres de treballar amb un rig:
Si es tracta d’un mapa d’articulacions humanoides (bípede, amb dos braços, un cap i una
columna més o menys erecta) el tractarà com a tal i ens permetrà modificar atributs més
específics com les formes que prenen els músculs en deformar-se. A més a més, gràcies a la
òbvia semblança entre diferents personatges humanoides, podem reutilitzar (o en anglès
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 27/101 Pau Montull i Jové
“retarget”) les mateixes animacions i Mecanim s’encarregarà que encaixin tot i que els
personatges siguin d’estatures diferents.
En canvi, si el rig no correspon a un personatge humanoide, haurem de fer una configuració
més complexa i no podrem fer servir animacions que no hagin estat creades específicament
per al mapa d’articulacions del nostre personatge.
La gestió de les transicions d’animacions es duu a terme mitjançant l’eina d’animació de
Mecanim, que permet crear i editar diagrames de flux per al control de les animacions. Hi ha
dos tipus de diagrames: els arbres de mescla (o “blend trees” en anglès) i les màquines d’estat
jeràrquiques (“Hierarchical State Machines”).
Com suggereix el nom, els arbres de mescla permeten mesclar diferents animacions
superposant-les en el mateix espai de temps segons els paràmetres que nosaltres hi
assignem.
Fig. 3.2.3: Arbre de Mescla de Mecanim
Les màquines d’estat jeràrquiques estableixen diversos estats d’animació d’un objecte
de joc i els relacionen entre ells segons les transicions necessàries per a passar d’un
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 28/101 Pau Montull i Jové
estat a l’altre. També ens permeten assignar animacions a cada estat i manipular
alguns paràmetres de les transicions.
Cada estat conté una seqüència d’animació o un arbre de mescla que serà reproduït
mentre es compleixin les variables necessàries perquè l’Objecte de Joc estigui en
aquest estat. Per exemple, prémer les tecles associades al moviment del jugador
activaria l’estat de moviment o l’arbre de mescla amb les animacions associades a
cada tecla premuda. De manera similar al funcionament dels arbres de mescla, les
transicions defineixen l’animació o mescla d’animacions que esdevé entre dos estats.
Fig. 3.2.4: Màquina d'Estat Jeràrquic de Mecanim
3.2.1.7 Renderització
El motor gràfic de Unity suporta shaders complexos i una alta quantitat de fonts de llum i
objectes per escena gràcies a les tècniques de renderització intel·ligent que inclou.
Unity conté 100 shaders i una multitud de materials i textures diferents per a aplicar als
diferents Objectes de Joc, a més a més de la possibilitat de crear-ne de nous o d’importar-ne
d’altres programes o de la botiga en línia de Unity (“Unity Asset Store”, a la pàgina web
https://www.assetstore.unity3d.com/).
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 29/101 Pau Montull i Jové
3.2.1.8 Efectes especials
El sistema de partícules “Shuriken” integrat a Unity permet la creació de partícules complexes
capaces d’interactuar amb l’entorn físicament. Shuriken també ens proporciona eines per a
modificar qualsevol aspecte artístic sobre les partícules, com el color, la brillantor, l’opacitat o
la massa.
3.2.1.9 Il·luminació
Unity compta amb un sistema de mapatge de llum (lightmapping) anomenat Beast. Aquest
sistema determina la situació de les ombres sobre els objectes de joc estàtics il·luminats per
llums que no canvien durant el joc, de manera que no s’hagin d’actualitzar mentre es juga i
millorant, així, el rendiment del joc. A part del mapatge de llum, Unity també conté llums
dinàmiques que si que són actualitzades en temps real quan canvien i interactuen amb
objectes mòbils.
3.2.1.10 Àudio
Unity conté filtres, equalitzadors i efectes d’àudio fàcils de personalitzar i accepta arxius
d’àudio en format MPEG, Ogg, WAV i AIFF.
3.2.1.11 Física
Unity fa servir el motor de física tridimensional “NVIDIA® PhysX®”, que ha estat adaptat per a
la física de cossos bidimensionals.
Aquest motor permet la creació de sòlids rígids amb masses determinades que interactuen
amb altres elements rígids i amb les forces que se’ls exerceix. Aquest motor també ens
permet crear elements de roba interactius amb l’entorn.
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 30/101 Pau Montull i Jové
3.2.2 ANÀLISI DE MOTOR DE JOC: “UDK”
“UDK (Unreal Development Kit) és la versió gratuïta d’Unreal Engine 3, que proporciona accés
a aquest motor de joc tridimensional i conjunt d’eines professional utilitzat en el
desenvolupament de videojocs professionals, visualització arquitectònica, desenvolupament
de jocs per a dispositius mòbils, renderitzat tridimensional, pel·lícules digitals i més.”
3.2.2.1 Gestió de recursos de joc
Al contrari que a Unity, a UDK no existeix un sistema modular de funcionalitats i objectes de
joc. En canvi hi ha uns objectes de joc amb unes característiques atribuïdes, per exemple el de
controlador de personatge. El fet que aquestes funcionalitats estiguin confinades a un sol
objecte de joc i no en siguin independents limita les possibilitats de creació d’objectes de joc
més sofisticats.
3.2.2.2 Gestió de l’espai virtual tridimensional
L’editor d’UDK funciona amb el concepte dels brushes, uns elements geomètrics que
permeten afegir o sostraure espai de l’escena virtual. Podem modificar la forma i dimensions
dels brushes a l’editor de UDK. Els brushes són un avantatge davant de les limitades malles
tridimensionals de Unity, ja que permeten modificar més extensament l’entorn tridimensional,
tot i no ser una eina de modelatge ideal, sobretot per a models detallats.
3.2.2.3 Interfície d’usuari
La interfície d’usuari de l’”Unreal Editor” de UDK és molt semblant a la de molts programes
d’edició i creació de contingut tridimensional. Tot i que es pot personalitzar, la disposició per
defecte de la interfície està dividida en quatre vistes de perspectiva del nivell de joc que estem
editant. A través dels menús superiors a cada una de les quatre vistes hi podem assignar
respectivament la vista de perspectiva i les vistes ortogràfiques de planta, alçada o frontal, i hi
podem triar la manera com representa el nivell cada vista segons si hi veiem només les malles
geomètriques o les textures sense o aplicant-hi els efectes de la il·luminació. A més a més de
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 31/101 Pau Montull i Jové
les quatre vistes que podem reorganitzar a la pantalla com ens convingui, trobem diferents
menús a l’editor d’UDK.
El menú superior conté els submenús “Fitxer”; on podem guardar, obrir, importar o exportar
arxius i projectes, “Editar”; on hi trobem les funcions típiques d’un programa d’edició
tridimensional com desfer, refer, copiar, enganxar..., “Vista”; on podem modificar les
característiques de les diferents vistes i triar quins elements s’hi poden veure, “Brush”; on
accedim a les eines per a treballar amb brushes i les opcions d’exportar i importar brushes,
“construeix”, on hi trobem les opcions de reconstruir geometries o actualitzar l’efecte de les
llums a més a més de la opció de provar el joc en el seu estat, i “Eines” on hi trobem l’editor de
formes bidimensionals i altres eines útils per a l’edició del nivell.
El següent menú des de dalt ens permet accedir a diferents exploradors d’elements per a
editar, importar i exportar elements d’altres programes. També trobem en aquest menú el
subprograma editor de text per a la programació.
Fig. 3.2.5: Interfície d'Usuari d'UDK
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 32/101 Pau Montull i Jové
3.2.2.4 Plataformes
El motor de desenvolupament UDK està disponible únicament per a Windows, però permet la
creació de videojocs per a Mac, Windows i iOS.
3.2.2.5 Programació
El llenguatge de programació de UDK és “Unreal Script”, un llenguatge de programació creat
específicament per a la creació de videojocs en aquesta plataforma que s’assembla a altres
com Java o C++ en la seva sintaxi.
A més a més, UDK compta amb un sistema de programació gràfica anomenat “Kismet”, que
permet la programació en una interfície de creació de diagrames de blocs interactius.
3.2.2.6 Animació
UDK suporta arxius de mapa d’articulacions, però no té editor específic per a la interpolació
d’animacions, en canvi haurem d’utilitzar el sistema de programació visual kismet, que no és
tan intuïtiu com el sistema Mecanim. Tampoc és capaç de reconèixer rigs humanoides ni de
gestionar el retargeting d’animacions per a aquests.
3.2.2.7 Renderització
UDK utilitza un sistema de renderitzat multi tasca basat en una arquitectura de 64 bits que
ens proporciona un potencial enorme pel que fa a tasques intensives per al processador com
el renderitzat de grans nombres de llums direccionals o malles geomètriques molt
subdividides.
3.2.2.8 Il·luminació
El motor d’il·luminació de UDK, “Lightmass” permet el renderitzat de llums i ombres d’alta
qualitat i en temps real.
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 33/101 Pau Montull i Jové
3.2.2.9 Àudio
UDK conté un sistema d’àudio basat en localització tridimensional que ajuda a la immersió del
jugador en el joc. Aquest sistema proporciona eines per a modificar to i volum i aplicar filtres o
moduladors, però només suporta arxius en format WAV.
3.2.2.10 Física
El motor de física de UDK està basat en la tecnologia “NVIDIA® PhysX®”, que permet la creació
de sòlids interactius amb les diferents acceleracions que els hi podem aplicar com podria ser
la de la gravetat. També és molt eficaç en la simulació de roba i elements tous que es
deformen en col·lidir amb d’altres.
3.2.3 AUTODESK MAYA
Maya® és un programa d’animació tridimensional que proporciona un conjunt complet de
funcions creatives per a realitzar animacions, modelatges, simulacions i renderitzats en una
plataforma de producció extensible.
3.2.3.1 Interfície d’usuari
La interfície de Maya està dividida en quatre regions principals: a la part superior hi trobem els
menús principals i l’anomenat menú d’estanteries, a la part inferior hi ha l’eix cronològic i la
barra de comandaments, a l’esquerra hi ha les eines d’ús habitual i les opcions de perspectives
de l’àrea de treball, a la dreta hi podem veure l’editor de capes i canals, i finalment al centre hi
ha l’àrea de treball.
La majoria de funcions de Maya són accessibles a través dels menús principals de la part
superior, just a sota hi trobem un menú desplegable que ens deixarà escollir quins d’aquests
menús es mostren segons quines funcions estiguem fent servir. D’aquesta manera, si estem
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 34/101 Pau Montull i Jové
creant una animació no ens molestaran els menús relacionats amb el modelatge. També es
pot triar quins menús preferim que es mostrin de forma personalitzada.
Les estanteries de Maya contenen d’una forma encara més accessible i intuïtiva les funcions
útils per a cada camp. Cada estanteria està dedicada a un camp del modelatge, l’animació o la
texturització, i també en podem fer de noves personalitzades i afegir-hi les eines que
desitgem.
L’eix cronològic ens permet navegar en el temps i crear fotogrames clau, a la seva dreta hi ha
un petit menú per a avançar i retrocedir fotograma a fotograma i parar o reproduir a temps
real.
La línia de comandaments serveix per a escriure-hi comandaments en el llenguatge de
programació “Python” per a automatitzar tasques molt feixugues com canviar la textura de
centenars d’objectes alhora.
Les eines d’ús habitual del menú de l’esquerra ens permeten interactuar directament amb els
objectes de l’àrea de treball vista d’escena, i també hi trobem les opcions per a modificar la
manera com veiem la vista d’escena, per exemple podem escollir el nombre de divisions que
tindrà i la perspectiva que hi veurem en cadascuna.
A l’editor de capes i canals podem modificar els atributs de l’objecte seleccionat de manera
precisa, a més a més de veure-hi totes les seves propietats.
Finalment, l’àrea de treball és la superfície d’interacció directa amb la geometria amb que
s’està treballant. Consta del seu propi menú superior, on podem determinar si hi veiem només
les línies de geometria (malla), només les superfícies (ombrejat suau), una combinació
d’aquests dos (malla ombrejada), les superfícies amb les seves textures bidimensionals
aplicades (texturitzat) i les superfícies texturitzades i amb l’efecte de les llums a l’escena
(il·luminat). A la pestanya de renderitzat d’aquest menú hi podem canviar la qualitat del
renderitzat de l’escena per a tenir una millor idea de l’acabament final però poder treballar en
un estàndard més assequible per a l’ordinador.
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 35/101 Pau Montull i Jové
Fig. 3.2.6 : interfície d'usuari de Maya.
3.2.3.2 Modelatge
En el món del modelatge tridimensional digital hi ha quatre camps principals: el modelatge
poligonal, la escultura digital, el modelatge per subdivisió de superfícies i el que s’anomena
modelatge amb NURBS. Cadascun d’aquests mètodes de creació de models tridimensionals
té les seves avantatges i desavantatges segons el tipus de model que es pretén aconseguir.
Per això Maya les integra totes, permetent una certa llibertat d’elecció de la metodologia del
procés de modelatge i el tipus d’acabat que n’obtindrem.
Maya té una infinitat d’eines de modelatge que permeten crear treballs complexos als
modeladors més experts, però també models competitius i igualment optimitzats als qui
acaben de començar.
3.2.3.3 Animació
Maya compta amb un sistema d’animació complet basat en interpolació entre fotogrames
clau, és a dir que per a crear una animació es posiciona l’objecte a animar i es marca el
fotograma de l’animació en el qual es troba en aquesta posició, després s’avança en el temps
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 36/101 Pau Montull i Jové
i es modifica la posició de l’objecte, finalment, en marcar el següent fotograma, el programa
calcula el moviment desitjat entre els dos fotogrames clau i el simula.
Tot i que pot semblar bàsic, aquest sistema és molt útil i intuïtiu, i la multitud d’opcions per a
canviar la manera com es simulen les interpolacions entre fotogrames clau proporcionen
llibertat per a crear animacions complexes i professionals.
Autodesk Maya consta d’un conjunt d’eines de rigging intuïtives i fàcils de manipular, per a
facilitar la tasca d’animació de personatges amb extremitats i articulacions complexes.
3.2.3.4 Textures i materials
Autodesk Maya ofereix una gran varietat de possibilitats per a crear textures, materials i
shaders d’alta qualitat.
A més a més de textures d’UV (imatges que s’emboliquen al model com una pell) Maya empra
mapes topològics, que usen la informació d’imatges en escala de grisos per a aconseguir que
un material tingui una certa rugositat sense afectar el processador de geometria. Així, en un
mapa topològic, els punts més foscos produiran valls i els més clars protuberàncies.
3.2.4 AUTODESK MUDBOX
Mudbox® és un programa d’escultura i pintura digital que permet la creació de recursos digitals
3D.
L’entorn d’alt rendiment i les eines professionals permeten la creació de personatges
altament realistes, escenaris participatius en l’escena, accessoris detallats i dissenys
conceptuals convincents en menys temps.
3.2.4.1 Escultura tridimensional
Al contrari que Maya o altres programes de modelatge tridimensional com Autodesk 3ds
Max®, Mudbox proporciona unes eines de modelatge molt més intuïtives per a un usuari
artista: en comptes de moure els vèrtexs i els vectors que conformen els models, l’usuari
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 37/101 Pau Montull i Jové
esculpeix i modela a partir d’una forma inicial, com si es tractés d’un tros de fang. Aquesta
manera de treballar fa més fàcil la creació de formes orgàniques i petits detalls.
3.2.4.2 Topologia
L’inconvenient principal de treballar amb models tridimensionals com si fossin d’argila és que
no tenim en compte directament com deformem la malla vectorial que els conforma; per tant
podríem acabar amb un model aparentment funcional però amb una malla asimètrica que
provocaria una mala animació del model. Per exemple, per a poder generar una animació de
l’articulació d’un braç, la malla geomètrica del braç n’ha de permetre els plecs.
Mudbox soluciona aquests problemes mitjançant eines de re-topologia intel·ligent i de
simetria topològica que ajusten la malla al model tridimensional a partir dels plecs, que podem
senyalar manualment o deixar que el programa analitzi el model per a deduir on són
necessaris.
3.2.4.3 Interoperabilitat amb Maya
Mudbox és compatible tant amb els formats de model tridimensional com els d’animació o de
textures, UVs i mapes de relleu de Maya. Degut a les seves possibilitats superiors a les de Maya
per a la escultura i la pintura precises de models tridimensionals, Mudbox acostuma a ser un
complement eficaç i productiu per a Maya. La interoperabilitat, ja mencionada, entre els dos
programes és per tant un gran estalviador de temps.
3.2.4.4 Interfície d’usuari
La interfície de Mudbox és molt senzilla i fàcil de personalitzar.
A la part superior hi trobem la barra de menús amb pestanyes desplegables.
A la pestanya “Arxiu” i ha opcions per gestionar les importacions i exportacions d’arxius, a
“Edita” hi trobarem opcions bàsiques d’edició de topologia, a la pestanya “Crea” hi ha eines per
crear malles, corbes, càmeres, llums i materials, al menú “Malla” hi trobem eines d’edició i
configuració de malles avançades, a “Mostra” hi ha les opcions per a configurar els elements
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 38/101 Pau Montull i Jové
visibles a la interfície, la pestanya “Mapes i UVs” serveix per a generar i gestionar mapes i UVs
a partir dels models amb els quals treballem, a la pestanya “Renderitza” hi trobem eines per
a generar imatges a partir d’una càmera de dins de l’entorn virtual que enfoqui el model amb
el que es treballa, a “Finestres” hi ha opcions per a configurar més específicament totes les
diferents finestres de la interfície i fins i tot afegir-ne d’inicialment amagades, i finalment, a
“Ajuda” hi trobem tutorials, referència i informació rellevant com la versió del programa.
Just a sota de la barra de menús hi ha una gran finestra que per defecte ocupa la vista de 3D,
l’espai virtual en el que es treballa modelant-hi o pintant a sobre dels models.
Clicant en les pestanyes adjacents a la de la vista 3D, que són la vista d’UV, l’explorador
d’imatges i la comunitat de Mudbox, podem fer servir aquest espai principal de la interfície per
a les aquestes altres vistes.
La vista d’UV, com el seu nom indica, ens mostra la malla UV del model present a la Vista 3D
desplegat, i en aquesta finestra hi podem fer modificacions per a encaixar vàries parts de la
mateixa malla en el mateix arxiu de textura.
L’explorador d’imatges és una finestra d’explorador d’arxius útil per a gestionar les imatges (o
textures) assignades al model amb el que es treballa d’una manera gràfica i intuïtiva.
La pestanya de comunitat de Mudbox és un lloc web accessible des del programa on hi podem
trobar una galeria d’imatges creades i compartides per usuaris del programa, una biblioteca
de models tridimensionals creats i publicats tant per usuaris com per desenvolupadors de
Mudbox i que es poden descarregar per a usar-los al programa.
A la dreta de la finestra principal hi trobem una finestra de capes també intercanviable
mitjançant un menú de pestanyes per la finestra d’objectes i la de filtres de la vista 3D.
A la finestra de capes hi ha les diferents capes del model present a l’escena, a la llista
d’objectes hi ha tots els objectes de l’escena organitzats en una llista en forma de jerarquia, i
a la pestanya de filtres de la vista 3D podem activar i desactivar diferents filtres per a modificar
la manera en que veiem els models.
Sota aquesta última finestra hi ha una finestra d’opcions, que ens permet modificar els atributs
de l’element seleccionat, ja sigui un model o el pinzell amb el que el modelem.
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 39/101 Pau Montull i Jové
Finalment, a la part inferior de la interfície hi trobem les eines d’escultura, les de pintura, les
d’edició de corbes, les de posat i les de selecció i moviment i diferents materials i formes del
pinzell preparades.
Tot i que aquest és l’ordre en que es troben les finestres en el moment en que obrim el
programa per primer cop, és veritablement fàcil modificar-ne la disposició arrossegant-les i
activant-les o desactivant-les a través del menú de finestres.
3.3 Fase de pre-producció
3.3.1 DOCUMENT DE DISSENY DEL JOC
3.3.1.1 Alt concepte
Un videojoc de trencaclosques lògics basats en un sistema de física que es pot modificar a
través dels controls del jugador. El jugador controla un personatge que es desperta en un
entorn desconegut i es veu forçat, per curiositat, per desesperació o per inèrcia a superar els
trencaclosques laberíntics cada cop més difícils amb els que es troba en el seu intent per
entendre què li està passant o progressar. Per a superar els laberints, el protagonista utilitza
dos dispositius que troba convenientment al principi del joc: l’un serveix per modificar
l’acceleració, direcció i sentit de la gravetat en disparar-lo dins del laberint i l’altre és una
pistola amb un garfi extensible per a impulsar-se o balancejar-se en aquest entorn. Els
controls es poden configurar en una interfície gràfica d’usuari i es visualitza l’acció a través
d’una càmera de primera persona. El videojoc està pensat per a la plataforma Windows.
3.3.1.2 Gènere
El gènere és el dels videojocs de trencaclosques, tot i que té característiques d’altres gèneres
com el fet que s’hagi de travessar nivells, dels jocs de plataformes o la vista en primera
persona, típica dels jocs de tir en primera persona.
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 40/101 Pau Montull i Jové
3.3.1.3 Jugabilitat bàsica
El jugador controla un personatge a través d’una càmera en primera persona i mitjançant un
teclat i un ratolí. Els botons del ratolí i el teclat es poden configurar per a controlar els diferents
aspectes del control del personatge. Per avançar en el joc el personatge ha d’aconseguir
travessar diferents nivells cada cop més difícils. Cada nivell és un espai tridimensional tancat
amb dues portes: una d’entrada i una de sortida. El personatge es pot moure lliurement per
aquestes habitacions que anomenem nivells i ha de travessar els obstacles que hi troba.
Per poder superar aquests obstacles s’haurà de servir de les dues eines que se li subministra
al començament del joc: la pistola de gravitons i el ganxo extensible.
La pistola de gravitons funciona en conjunció amb uns aparells fixats a les superfícies dels
nivells (a les parets, als terres o als sostres) i senyalitzats com a ports de la gravetat. La pistola
permet al jugador modificar el vector d’acceleració de la gravetat del nivell: si es dispara amb
la pistola contra un port de la gravetat la gravetat del nivell canvia. El vector director de la
gravetat resultant és normal a la superfície on estigui fixat el port de la gravetat disparat. Així
es podria dir, per exemple, que quan es dispara un port fixat en una paret la gravetat passarà
a estirar tots els objectes mòbils cap a aquella paret, com si aquesta hagués esdevingut el
terra.
El ganxo extensible funciona en conjunció amb uns ganxos fixats a les superfícies dels nivells
(a les parets, als terres o als sostres), i permet que el personatge es gronxi de la cadena que
dispara aquest dispositiu: quan el jugador dispara contra un ganxo fixat a una superfície del
nivell una llarga cadena surt del dispositiu de ganxo extensible i s’ancora al ganxo fix
permetent que el jugador es pengi i es gronxi amb la cadena.
Combinant aquestes dues mecàniques de joc es pot travessar tots els nivells del joc.
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 41/101 Pau Montull i Jové
3.3.1.4 El diagrama de controlador
Fig. 3.3.1 : Diagrama de controlador del joc (en la configuració estàndard)
3.3.1.5 La interfície d’usuari durant el joc
La interfície d’usuari durant el joc serà molt senzilla: els únics elements que es mantindran en
pantalla constantment són les dues eines del personatge i un punter al mig de la pantalla per
tenir referència d’on es dispara. També apareixerà a la pistola de gravitons una pantalla amb
un comptador que baixarà constantment des d’una hora i quan arribi a zero es reiniciarà
sempre en el valor doble de l’últim reinici. Aquest comptador és un recurs narratiu per causar
curiositat al jugador, tot i que no sigui realment rellevant per la història.
3.3.1.6 Menús i interfície gràfica principal
La interfície gràfica principal serà molt senzilla. De fet serà tant senzilla que el menú de pausa
i el d’inici seran el mateix:
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 42/101 Pau Montull i Jové
Fig. 3.3.2 : Menú principal i de pausa del joc
El menú d’opcions comptarà amb els botons de desplaçament per escollir la configuració de
qualitat i el volum.
Fig. 3.3.3 : Menú d’opcions.
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 43/101 Pau Montull i Jové
El menú de controls serà una llista dels controls del joc i les tecles automàticament assignades
a cada control. Les tecles es podran re-assignar clicant sobre el nom del control i polsant la
tecla que hi volem assignar en comptes de l’actual.
Fig. 3.3.4 : Menú de controls
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 44/101 Pau Montull i Jové
Fig. 3.3.5: Diagrama de navegació de la interfície gràfica principal del joc.
3.3.1.7 Gestió i balanç de les mecàniques de joc
- Mecànica de canvis de la gravetat: Per usar-la es necessita la pistola de gravitons que
s’obté al nivell 0. Només es pot canviar la gravetat disparant un port de gravitons amb
la pistola. La gravetat resultant del canvi sempre tindrà un vector director normal a la
superfície del port de gravitons.
- Mecànica de ganxo extensible: Per usar-la es necessita el dispositiu de ganxo
extensible que s’obté al nivell 2. Només es pot disparar un ganxo extensible si s’apunta
a un ganxo fix. Es pot disparar en qualsevol moment sempre que es compleixin les
condicions anteriors. Disparar apuntant alguna cosa que no sigui un ganxo fix retorna
el ganxo extensible al dispositiu plegant tot el cable i alliberant el ganxo si aquest
estava ancorat a un ganxo fix.
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 45/101 Pau Montull i Jové
3.3.1.8 Entorn
L’entorn del joc és un món laberíntic virtual. Aparentment tot ha estat preparat perquè el
protagonista segueixi el laberint, com si al final hagués de trobar-hi un motiu, però l’únic
descobriment que hi troba és la futilitat dels seus esforços per progressar. El laberint és
monòton i gris, i tot sembla estar pintat amb aquarel·la i repassat amb retolador negre. El
color predominant és el gris, tot i que es pot trobar llums de colors i algunes finestres a
escenaris desconcertants per captar l’atenció del jugador.
3.3.1.9 Personatges
L’únic personatge del joc és el protagonista, i de fet no l’arribem a veure mai, ja que la càmera
no es mou de la seva visió en primera persona. El protagonista és l’únic narrador de la història;
no té interlocutors, i la motivació del jugador per superar els obstacles del laberint és trobar
una explicació a la situació del personatge dins del joc. El soliloqui espontani del protagonista
provoca la empatia del jugador que vol ajudar-lo a descobrir el sentit del laberint.
3.3.1.10 Disseny de nivells, missions i àrees
Fig. 3.3.6 : Diagrama vectorial isomètric del primer nivell.
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 46/101 Pau Montull i Jové
Fig. 3.3.7: Diagrama vectorial isomètric del segon nivell.
3.3.2 DOCUMENT DE DISSENY TÈCNIC
3.3.2.1 Metodologia de desenvolupament
Basant-me en la investigació del bloc anterior, tenint en compte el tipus de joc que vull fer i
que gairebé no tinc cap experiència programant, modelant o fent servir el motor de joc, he
dissenyat una metodologia de treball modular i iterativa (semblant a la de desenvolupament
àgil) que penso que m’ajudarà a ser més productiu i a no encallar-me en problemes petits amb
els quals òbviament em trobaré.
Seguidament, descriuré la metodologia de desenvolupament escollida per al meu videojoc:
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 47/101 Pau Montull i Jové
Primerament organitzaré les tasques a fer en una jerarquia de nivells segons la immediatesa
amb la que s’han d’implementar. Així, en el primer nivell hi
haurà les tasques inevitables per al progrés del
desenvolupament. Les tasques del mateix nivell estaran
separades en mòduls que es puguin implementar de
manera independent respectivament, i al contrari,
les tasques de cada nivell inferior sempre
dependran de les del nivell anterior. Així, si
per qualsevol raó m’encallés en un mòdul,
sempre n’hi hauria d’altres d’importància
semblant en el mateix nivell que podria
implementar i tornar al primer més tard havent-hi pensat
més estona o amb una perspectiva més fresca.
Un cop desglossades i ordenades les tasques, les completaré individualment, una a una i
seguint el diagrama de la figura 3.2.2.
3.3.3 COMPARACIÓ ANALÍTICA DELS MOTORS DE JOC ESTUDIATS
Sens dubte la decisió més important a prendre en l’àmbit de la elecció del programari és la del
motor de joc, ja que aquest programa serà la base del videojoc. És per aquesta raó que basant-
me en l’anàlisi previ dels motors de joc que he estudiat i després d’instal·lar-los i provar-los,
he avaluat de l’1 al 10 cada una de les funcions que considero de més rellevància en cadascun
i les he comparat en una taula què és la següent:
Unity UDK
Gestió de recursos de joc 10 6
Gestió de l’espai virtual tridimensional 7 9
Interfície d’usuari Facilitat d’ús 10 9,5 4 5,5
Fig. 3.3.8 : Procés iteratiu de desenvolupament per cada mòdul
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 48/101 Pau Montull i Jové
Modularitat i
personalització 9 7
Compatibilitat amb altres programes i
capacitat per a exportació a diferents
plataformes
10 8
Programació
Flexibilitat 10
9,5
9
9 Integració del
llenguatge o sistema
amb el motor de joc
9 9
Animació
Flexibilitat 10
10
5
6 Integració amb el
motor de joc 10 7
Renderització i Materials i Efectes Especials 9 8
Il·luminació 7 9
Àudio 8 7
Física 10 10
Mitjana 9 7,75
El resultat d’aquesta comparació és favorable al motor de joc “Unity Free”, els punts més forts
del qual són la facilitat d’ús i la flexibilitat. S’ha de tenir en compte, però, què per un tema
pràctic, he analitzat les versions gratuïtes d’ambdós programes, i la diferència entre ells i les
seves versions de pagament és més gran en el cas d’UDK i Unreal 4 que en el de Unity Free i
Unity.
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 49/101 Pau Montull i Jové
3.3.3.1 Anàlisi i elecció del motor de joc
A partir de l’anàlisi de programari dels motors de joc “Unity Free” i “UDK” fet en els apartats
3.2.1.1 i 3.2.1.2 i de la taula comparativa dels dos, a l’apartat 3.2.1.3, he decidit que la millor
opció per al desenvolupament del meu videojoc serà utilitzar Unity. Tenint en compte la meva
poca experiència amb programari d’aquest tipus crec que un programa tant fàcil d’utilitzar
com Unity serà més efectiu que “UDK”, que potser té més potencial en alguns aspectes, però
és molt complex i poc intuïtiu de fer servir.
3.3.3.2 Anàlisi i elecció de programari artístic
De l’anàlisi dels programes “Maya” i “Mudbox” de l’empresa Autodesk7 he decidit fer servir
Maya. Tot i que són dos programes perfectament compatibles entre ells i es recomana fer-los
servir de manera complementària, no crec que sigui necessària la precisió per als detalls de
Mudbox.
3.4 Producció
3.4.1 DESGLOSSAMENT DE LES TASQUES EN MÒDULS
Com s’ha explicat al Document de Disseny del joc, el primer pas del procés que faré servir per
a desenvolupar el videojoc consisteix en separar les tasques previstes en mòduls o blocs que
es puguin realitzar de forma independent i ordenar-les segons la immediatesa amb la que cal
realitzar-les.
He dut a terme el desglossament de tasques tal com es pot veure en el següent diagrama:
7 L’accés als dos programes, que són de pagament, l’he aconseguit a partir d’un compte educacional d’Autodesk, que he fet a la seva pàgina web i introduint-hi el correu de l’institut.
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 50/101 Pau Montull i Jové
Fig. 3.4.1 : Desglossament de tasques en mòduls i jerarquia de nivells de prioritat
3.4.2 ENTORN DE DESENVOLUPAMENT ITERATIU
Un cop dins del motor de joc escollit, Unity, i abans de començar a implementar els primers
mòduls, he fet uns ajustos preparatoris:
- En una escena nova que em servirà per a provar-hi els mòduls implementats he ajustat la
interfície d’usuari al meu gust.
Com que les primeres tasques que hauré de realitzar són bàsicament de configuració i
programació, he ampliat la vista d’inspector on sortiran els paràmetres dels objectes de
joc i he reduït les vistes de joc i la d’escena. He situat la Llista de Jerarquia, la consola i la
vista de projecte al costat de la vista d’inspector. El resultat és la meitat de la pantalla
dedicada a les dues vistes gràfiques (la d’escena i la de joc) i l’altra meitat a la gestió
d’arxius i d’errors (vistes d’inspector, de projecte, de jerarquia i de consola):
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 51/101 Pau Montull i Jové
Fig. 3.4.2 : Configuració personal de la interfície de Unity.
- Després he preparat un entorn agradable a l’escena per a treballar-hi a sobre; hi he afegit
un terra pla provisional per poder provar el personatge que crearé més endavant. També
hi he afegit una capsa de cel predeterminada i una llum unidireccional bàsica per generar
un fons amb contrastos que em doni una millor idea del que està passant a l’escena quan
els objectes es moguin:
Fig. 3.4.3 : Escena de proves amb una capsa de cel de núvols, una llum direccional i un pla per al terra.
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 52/101 Pau Montull i Jové
3.4.3 NIVELL 1
3.4.3.1 Mecànica de moviment bàsic del jugador
El del protagonista és segurament l’objecte de joc més important del meu videojoc, ja que
desencadena la funció de punt de vista del jugador i d’eina d’interacció amb el joc. És per
aquesta raó que el crearé el primer.
Les característiques del meu personatge principal han de ser aquestes:
- Ha de comptar amb una càmera en primera persona
- Ha de rotar en l’eix X en moure el ratolí de dreta esquerra o d’esquerra a dreta i ha de rotar
la càmera en l’eix Y en moure el ratolí de dalt a baix o de baix a dalt.
- Ha d’interactuar amb la física integrada a Unity o simular-la a través de codi de manera
precisa i ha d’interactuar amb altres objectes de tipus cos rígid.
3.4.3.1.1 Controlador estàndard (primer intent)
Una de les avantatges de fer servir un motor de joc tan complet com Unity són els anomenats
recursos estàndard (Standard Assets en anglès): els creadors de Unity, i per tant els qui millor
coneixen el programa, han preparat una sèrie de recursos prefabricats a la disposició de
l’usuari. Aquests recursos són des de controladors de personatge en primera i tercera persona
fins a “shaders” o petits fragments de codi per a funcions molt freqüents, i són exemples de
quina pensen els desenvolupadors del motor de joc que és la millor manera d’implementar
aquests recursos en qualsevol joc.
En el meu cas, la creació del protagonista comença amb el controlador de personatge en
primera persona prefabricat, que es troba a la carpeta “Assets\Standard Assets\Character
Controllers”.
Després d’importar l’objecte de joc “First Person Controller” en faig una anàlisi a fons per a
poder decidir si en el cas del meu videojoc serà un recurs perfectament funcional, si l’hauré de
modificar lleugerament, o si seria més adequat fer-ne un des de zero.
L’objecte de joc “pare”, el controlador de personatge, conté uns altres components:
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 53/101 Pau Montull i Jové
El primer de tots , el component Transform està present en tots els objectes de joc de la versió
actual de Unity. Transform designa a l’objecte de joc una posició en les tres dimensions, una
rotació expressada en angles d’Euler i la seva mida respecte les proporcions originals de
l’objecte.
Fig. 3.4.4 : Component transform de l'objecte
Aquest component està dissenyat específicament per a crear tant controladors de personatge
en tercera com en primera persona.
Segons la documentació de Unity:
“El (component de) Controlador de Personatge es fa servir bàsicament per al control de
personatges en tercera o primera persona que no fan servir física de Rigidbody (física de
cossos rígids).”8
La definició d’aquest component em proposa el primer inconvenient: aquest controlador de
personatge mai podrà interactuar amb el sistema integrat de física de Unity, i per tant això em
complicaria la implementació de les mecàniques de ganxo extensible i de canvis de gravetat;
en comptes d’assignar-li una massa i simular les forces que trobaríem a la vida real, hauria de
modificar la seva posició en el temps a través d’un programa.
Fig. 3.4.5 : Component de controlador de personatge.
Seguidament trobem el component de programa C# anomenat “Mirada de Ratolí” (Mouse
Look en anglès).
8 http://docs.unity3d.com/Manual/class-CharacterController.html. Traduït per Pau Montull
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 54/101 Pau Montull i Jové
Aquest component rota el nostre objecte de joc, i per tant també els seus “fills” només en l’eix
X a partir de l’increment de moviment del ratolí en el mateix eix.
Podem ajustar les variables per a limitar el moviment i ajustar la sensibilitat del ratolí.
Fig. 3.4.6 : Component de mirada de ratolí.
Els següents components de programa javascript controlen el moviment de l’objecte de joc
modificant els paràmetres del component Transform en el temps a partir de l’entrada de les
tecles de moviment “WASD”. També gestionen els salts i soluciona situacions com pendents
massa inclinades per caminar-hi fent que el personatge hi rellisqui controladament.
Aquest programa funciona a partir de les variables del component de Controlador de
personatge.
Fig. 3.4.7 : Component de motor de personatge i entrada de controlador FPS.
A la vista de la jerarquia podem veure que l’objecte del controlador de personatge en primera
persona és pare d’un parell d’objectes.
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 55/101 Pau Montull i Jové
Si mirem els components dels dos “fills” del
controlador descobrirem que l’un, l’anomenat
“Gràfics”, conté un objecte geomètric en forma de
càpsula que simbolitza l’espai ocupat en tot moment
pel personatge, i l’altre, la “Càmera Principal” fa la
funció de càmera en primera persona i conté un
programa en llenguatge C# que rota aquesta càmera
només en l’eix Y amb uns límits que podem modificar
fàcilment en les variables inicials del programa.
Tot i que aquest controlador funciona perfectament en el terra pla de prova en provar-lo a la
vista de joc, la gran complexitat dels seus components i el fet que compliqui tant la interacció
amb la física (que és, al cap i a la fi, un dels focus temàtics del meu joc), em decideixen a crear
un controlador de personatge nou.
3.4.3.1.2 Controlador amb component de cos rígid (segon intent)
Després de descartar els controladors per defecte, que no admeten el component de cos rígid
que els permet interactuar amb la física, he fet una recerca a fons a internet de projectes de
controladors de personatges de Unity amb aquest component.
He trobat diversos programes controladors de personatge per a Unity basats en cossos rígids,
la majoria interpretacions o modificacions d’un d’anomenat “RigidbodyFPSWalker”. Aquest
últim és un programa senzill i relativament fàcil d’entendre i sembla que podria ser una bona
base per crear un controlador des de zero.
La pàgina web de la wiki de Unity on he trobat el programa “RigidbodyFPSWalker” el
descrivia de la següent manera:
“Això és un controlador de personatges en primera persona basat en un cos rígid.(...) Les forces
afecten automàticament el cos rígid(...). El programa funciona afegint força en la direcció del
moviment desitjat, sostreu la velocitat actual per a aconseguir parar si no es prem cap tecla.(...)”
9
9 http://wiki.unity3d.com/index.php?title=RigidbodyFPSWalker#Usage. Traduït per Pau Montull.
Fig. 3.4.8 : Jerarquía del projecte.
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 56/101 Pau Montull i Jové
Degut a aquestes característiques, el programa em serà molt útil com a base per al
desenvolupament del meu controlador de personatge:
Per crear el meu propi controlador començaré creant una capsula geomètrica que simbolitzi
el cos del jugador. Prendré com a unitat de referència per al joc els estàndards de Unity. Així
les mesures del personatge seran les d’una una càpsula estàndard, d’escala (x, y, z) = (1, 1, 1),
que fa 2 unitats d’altura i 0,5 de radi.
Fig. 3.4.9 : El fet d'inserir un objecte de joc 3D de càpsula ja li assigna automàticament un component de transformació, un component de malla 3D i un renderitzador de la malla.
Després afegiré un component de Col·lisionador de Capsula i un altre de Cos Rígid, ja que són
necessaris per què el programa “RigidbodyFPSWalker” funcioni correctament.
També afegiré un Component Mirada de Ratolí per associar la rotació del personatge en l’eix
X al desplaçament del ratolí.
Fig. 3.4.10 : Components de col·lisinador de càpsula, de cos rígid i de mirada de ratolí, aquest últim configurat per l’eix X únicament.
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 57/101 Pau Montull i Jové
Finalment afegiré el component de programa de Javascript del “RigidbodyFPSWalker”.
A continuació mouré l’objecte de joc de Càmera Principal sota l’objecte del controlador per
fixar la càmera al controlador de manera que el segueixi des de la posició del cap. Ara la
càmera es mou amb el personatge, però encara no es pot mirar cap a baix ni a dalt. Per a
aconseguir aquest efecte afegeixo un component de Mirada de Ratolí en l’eix Y.
Fig. 3.4.11 : relació jeràrquica entre la càpsula i la càmera a la vista de jerarquia (esquerra) i component de mirada de ratolí configurat perquè actuï només en l'eix Y (esquerra).
Fig. 3.4.12 : Posicionament de la càmera a l'alçada del cap del personatge a la vista d'escena.
El resultat de seguir els passos mencionats és un personatge funcional controlat en primera
persona, però està lluny de ser un producte final.
3.4.3.2 Mecànica dels canvis de direcció i sentit de la gravetat
Com queda descrit al GDD, aquesta mecànica converteix el vector director de la gravetat en el
de la normal a la superfície d’impacte d’un tret de la pistola de gravitons; per tant, els
requeriments per a implementar-la seran els següents:
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 58/101 Pau Montull i Jové
- Un objecte de joc “port de gravitons” la rotació del qual determinarà la gravetat resultant
quan el jugador el dispari amb la pistola de gravitons. Aquest objecte de joc ha de ser
fàcilment reproduïble, ja que al joc n’hi ha d’haver molts i tots han de funcionar de la
mateixa manera.
- Un objecte de joc “pistola de gravitons” que pugui manipular el jugador per apuntar i
disparar ports de gravitons per canviar el sentit i direcció de la gravetat.
3.4.3.2.1 Canvi del vector gravetat de l’escena a través del codi (primer intent)
Començaré per crear l’objecte de joc “pistola de gravitons”. Per fer-ho insereixo un objecte de
joc 3D de tipus cilindre (com que no és de vital importància per al funcionament de la mecànica
la creació del model tridimensional de la pistola està en un nivell de prioritat inferior i per tant
fins que hi arribi empraré objectes de joc senzills que tinguin una forma i mida aproximats).
Seguidament subordinaré l’objecte de joc creat a la càmera principal, ja que l’objectiu de la
pistola ha d’apuntar sempre el punt central de la vista del personatge perquè rotant la càmera
pugui apuntar. Després escalaré i posicionaré el cilindre de manera que estigui present a la
vista de joc però no tapi tota la pantalla (ha de donar la sensació que en aquesta vista es veu
a través dels ulls del personatge i la pistola, a la seva mà esquerra, li segueix la mirada).
Fig. 3.4.13 : Ordre jeràrquic de la pistola de gravitons a la vista de jerarquia (esquerra) i els seus components a la vista d’inspector (dreta).
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 59/101 Pau Montull i Jové
Fig. 3.4.14 : posicionament de l'objecte de joc "pistola de gravitons" (vista d'escena a l'esquerra i vista de joc a la dreta)
Seguidament crearé l’objecte de joc “port de gravitons”. Aquest cop el representaré com un
pla bidimensional en l’espai tridimensional, per la simplicitat que suposa tenir una superfície
perfectament plana on apuntar i també l’impacte menor que té en el rendiment del joc, ja que
el motor només n’ha de renderitzar una cara. El subordino al pla que representa el terra per
agrupar els objectes de joc que formaran part de la geometria estàtica del joc. Després el
posiciono a l’aire sobre el jugador, en una rotació diferent a la del terra, per poder provar més
endavant l’eficàcia dels canvis de gravetat i la del controlador de personatge en haver canviat
la gravetat.
Fig. 3.4.15 : Vista de jerarquia amb el port de gravitons subordinat al pla (terra) de la geometria estàtica a la vista de jerarquia (esquerra) i rotació i escalament del port de gravitons a la vista d’inspector (dreta).
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 60/101 Pau Montull i Jové
Fig. 3.4.16 : Posicionament final del port de gravitons a la vista d’escena.
Per assignar la propietat de port de gravitons a aquest pla
geomètric faré servir una funcionalitat de Unity anomenada
“capes”: primer accediré al menú d’etiquetes i capes a través del
menú desplegable d’edició i la pestanya de configuració de
projecte. Des d’aquest menú assignaré, donant-li el nom de
“gravitonPort”, la capa número vuit (lliure per defecte) als ports
de gravitons, per poder referir-m’hi més tard al programa de
canvis de direcció i sentit de la gravetat.
Fig. 3.4.18 : Capa de port de gravitons (capa 8) al menú d’etiquetes i capes de la pestanya de configuracions de projecte.
Després de nombrar la capa vuit, configuro l’objecte de joc “Port de gravitons” creat
anteriorment perquè hi pertanyi.
Fig. 3.4.17 : Accés al menú d’etiquetes i capes la pestanya de configuracions de projecte.
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 61/101 Pau Montull i Jové
Fig. 3.4.19 : Configuració de capa de l’objecte de joc “Port de gravitons” a la vista d’inspector.
Un cop creats els objectes de joc necessaris i assignat el port de gravitons a la seva capa
corresponent, crearé un programa per gestionar els canvis del vector de la gravetat en funció
dels trets de la pistola de gravitons:
El motor de física de Unity (“PhysX”) compta, per defecte,
amb un paràmetre anomenat “gravetat”. Aquest paràmetre
és un vector tridimensional que es pot modificar manualment
o a través del comandament “Physics.gravity” en un
programa. El paràmetre gravetat es troba en un menú de
configuració del projecte de Unity anomenat Física. Hi podem
accedir, per tant, des del menú desplegable d’edició i sota la
pestanya de configuració de projecte.
Fig. 3.4.20 : Accés al menú de física a la pestanya de configuració de projecte de
Unity.
Fig. 3.4.21 : Menú de configuració de projecte de Unity dedicat al motor de física. (a la part superior del menú) Vector tridimensional “gravetat” modificable manualment o a través de codi.
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 62/101 Pau Montull i Jové
Per gestionar els canvis de gravetat he escrit el programa explicat a continuació:
Fig. 3.4.22 : Programa “gravityTarget” per gestionar els canvis de gravetat en funció de l’ús de la pistola de gravitons.
Aquest programa crea el que s’anomena un “Raycast”, un raig virtual definit per els vectors
tridimensionals que li donem (en aquest cas el punt de la pantalla que en representa el centre
i la direcció de al mirada) i en accionar el botó de disparar 1 comprova que el raig no estigui
xocant amb cap objecte de joc dins de la capa de ports de gravitons; en cas contrari converteix
el vector director de la gravetat en el vector negatiu de la normal de l’objecte que ha
interromput el raig.
Després d’escriure aquest programa l’aplico com a component a la pistola de gravitons i
comprovo el funcionament correcte del programa:
Com que el programa controlador de personatge “RigidbodyFPSWalker” fa servir una
acceleració de la gravetat especificada a les variables inicials, els canvis de la gravetat de
l’escena no l’afecten. Ho soluciono aplicant la gravetat de l’escena al controlador de
personatge:
Ara el personatge ja queda afectat pels canvis de gravetat, però el fet que per permetre’n el
control, el programa “RigidbodyFPSWalker” n’anul·li la rotació en l’eix Y i Z evita que el
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 63/101 Pau Montull i Jové
personatge pugui girar amb l’entorn quan la gravetat canvia. Per tant, aquest no és capaç de
caminar per les superfícies que en canviar la gravetat esdevenen el terra.
Aquest últim no és un problema tant fàcil de solucionar, ja que el requisit principal dels cossos
rígids és que només es poden moure per forces aplicades a través del motor de física, i per
tant no es poden rotar en temps real fent modificacions al seu component de transformació.
3.4.3.2.2 Rotació del cos per aplicació de moment (segon intent)
Una possible solució seria afegir moment al cos, però el mètode per afegir moment al cos és
molt poc precís, i no hi ha cap comandament que et permeti calcular concretament els
moments necessaris a aplicar perquè el cos interpoli la seva rotació entre l’actual i la normal
a la superfície destí. El comandament “AddTorque” per afegir moments està pensat més aviat
per simular la rotació d’una baldufa o la d’un objecte que surt disparat d’una explosió, i no per
a tasques tant precises com aquesta.
3.4.3.2.3 Rotació de l’entorn tridimensional aparentment estàtic (tercer intent)
Una altra solució seria modificar el programa de gestió dels canvis de la gravetat perquè rotés
l’entorn gràfic aparentment estàtic de manera que la gravetat variés sempre dins el context
de l’entorn interior però no a l’escena. Aquesta segona opció tampoc dóna bons resultats, ja
que rotar tant bruscament l’entorn comporta errors de posició del personatge molt greus, que
el fan sortir sobtadament de l’escena i caure al buit (el canvi de posició de les parets ha de ser
tant ràpid que no dóna temps al motor de física de calcular les col·lisions del personatge amb
les parets i aquest les travessa). Tampoc és convenient rotar l’entorn sencer a partir de la
posició d’un objecte de joc subordinat com és el port de gravitons.
3.4.3.2.4 Ús de la funcionalitat de cos rígid cinemàtic (quart intent)
En comptes de tot això he decidit fer servir la funcionalitat “cos rígid cinemàtic”, que permet
convertir cossos rígids en cossos estàtics temporalment, i així modificar-ne el component
transform sense problemes.
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 64/101 Pau Montull i Jové
He creat una funció dins el programa controlador del personatge que permet que en canviar
la gravetat aquest es converteixi momentàniament en un cos rígid cinemàtic per poder
interpolar entre la seva rotació actual i la normal a la superfície destí:
Aquesta funció ha estat la millor de les solucions fins ara, però encara deixa un altre problema
i és com determinar el moment en el qual és apropiat rotar cinemàticament el personatge, ja
que convertir un cos rígid en cinemàtic li fa perdre qualsevol inèrcia que portés.
- Una possible solució seria rotar el personatge en el moment en que canvia la gravetat.
Aquesta solució funcionaria si només es pogués modificar la gravetat des d’una posició
estàtica, però una de les funcionalitats clau del videojoc ha de ser el dinamisme i el canvi
de la gravetat sobre la marxa, per poder acumular l’acceleració centrípeta d’un moviment
de balanceig per impulsar-se cap un altre indret; aquesta solució no permetria aquest
dinamisme i per tant queda descartada.
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 65/101 Pau Montull i Jové
- Una altra solució seria detectar el moment en que el personatge impacta físicament amb
la superfície destí. Aquesta solució és més adient, però resulta extremadament difícil
detectar l’impacte del personatge amb una superfície específica, i el personatge tendeix a
encallar-se en bucles de rotació infinits.
La solució que he triat és una barreja de les dues anteriors: només rotarà si la velocitat del cos
és molt pròxima a zero i ha canviat la gravetat. Així es conserva la inèrcia sempre que sigui
considerable, i té el benefici addicional de no rotar la càmera tant sovint i de fer-ho quan està
parada, així que no provoca mareig i dóna més sensació d’estabilitat al jugador.
Ara el personatge és capaç de moure’s pel terra establert inicialment i de canviar la gravetat i
rotar per poder caminar sobre les parets o els sostres, però com que el “RigidbodyFPSWalker”
no ha estat programat específicament per fer aquestes coses, encara he de fer algunes
modificacions més a aquest programa:
- En comptes de limitar la velocitat a través del comandament “Mathf.Clamp()”, com en el
programa original, es limita multiplicant la variable velocitat pel vector unitari de la
velocitat desitjada (què depèn directament de la entrada de les tecles de moviment del
jugador).
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 66/101 Pau Montull i Jové
3.4.3.3 Mecànica de ganxo extensible
Els requeriments de la mecànica de ganxo extensible són els següents:
- Un objecte de joc “ganxo extensible” que dispari un cable virtual que permeti al
personatge gronxar-se d’ell.
- Un objecte de joc “ganxo fix” que permeti al ganxo extensible ancorar-s’hi.
Començaré per crear el ganxo extensible, que per semblança pot ser un duplicat modificat de
la pistola de gravitons. Per tant duplicaré la pistola, li canviaré el nom i li trauré el component
de gestió de canvis de la gravetat. També la posicionaré a l’altre costat del personatge, perquè
doni la sensació, en mirar la vista de joc, que el personatge la subjecta amb la mà dreta.
Fig. 3.4.23 : Objecte de joc “Ganxo extensible” a la vista de jerarquia (esquerra) i a la d’inspector (dreta).
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 67/101 Pau Montull i Jové
Després crearé un objecte de joc de tipus esfera per simular el ganxo fix, i de la mateixa
manera que amb el port de gravitons, el subordinaré a la geometria estàtica i li assignaré una
capa específica que anomenaré “grapplingPort”.
Fig. 3.4.24 : Configuració de capa de l’objecte de joc “Ganxo fix” a la vista d’inspector (dreta) i ordre jeràrquic a la vista de jerarquia (esquerra).
Finalment queda programar la funcionalitat del ganxo extensible, i per això he fet un programa
anomenat “grapplingShot” que envia un raig (un “Raycast”) en la direcció en la que apunta el
jugador. Si el raig és interceptat per un objecte pertanyent a la capa “grapplingPort” i el
personatge no està, ja, ancorat i es clica el botó de disparar 2 el programa passa la informació
de l’ancoratge al programa controlador de personatge i mostra el cable des del ganxo
extensible fins el fix.
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 68/101 Pau Montull i Jové
El següent desafiament el trobem en la manera de simular el moviment circular accelerat que
suposa el balanceig del personatge.
3.4.3.3.1 Simulació de forces (primer intent)
La solució més òbvia és simular, mitjançant el motor de física, la força centrípeta del cos del
personatge a partir de la distància des del cos fins el punt d’ancoratge, la massa del cos i la
seva velocitat actual:
𝐹𝑐𝑒𝑛𝑡𝑟í𝑝𝑒𝑡𝑎 =𝑚 · 𝑣2
𝑟
On
𝑟 = 𝑑𝑖𝑠𝑡à𝑛𝑐𝑖𝑎 𝑑𝑒𝑙 𝑐𝑜𝑠 𝑎 𝑙′𝑎𝑛𝑐𝑜𝑟𝑎𝑡𝑔𝑒, 𝑟𝑒𝑝𝑟𝑒𝑠𝑒𝑛𝑡𝑎𝑡 𝑝𝑒𝑟 𝑙𝑎 𝑣𝑎𝑟𝑖𝑎𝑏𝑙𝑒 "𝑑𝑖𝑠𝑡𝑇𝑜𝐴𝑛𝑐ℎ𝑜𝑟"
𝑣 = 𝑣𝑒𝑙𝑜𝑐𝑖𝑡𝑎𝑡 𝑎𝑐𝑡𝑢𝑎𝑙 𝑑𝑒𝑙 𝑐𝑜𝑠, 𝑒𝑥𝑡𝑟𝑒𝑡𝑎 𝑎𝑚𝑏 𝑒𝑙 𝑐𝑜𝑚𝑎𝑛𝑑𝑎𝑚𝑒𝑛𝑡 "𝑟𝑖𝑔𝑖𝑑𝑏𝑜𝑑𝑦. 𝑣𝑒𝑙𝑜𝑐𝑖𝑡𝑦"
𝑚 = 𝑚𝑎𝑠𝑠𝑎 𝑣𝑖𝑟𝑡𝑢𝑎𝑙 𝑑𝑒𝑙 𝑐𝑜𝑠, 𝑒𝑥𝑡𝑟𝑒𝑡𝑎 𝑎𝑚𝑏 𝑒𝑙 𝑐𝑜𝑚𝑎𝑛𝑑𝑎𝑚𝑒𝑛𝑡 "𝑟𝑖𝑔𝑖𝑑𝑏𝑜𝑑𝑦. 𝑚𝑎𝑠𝑠"
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 69/101 Pau Montull i Jové
Aquest fragment de programa hauria de simular un moviment circular molt precís i semblant
a com es comportaria una massa a la realitat, ja que simula directament la força centrípeta de
la corda estirant el cos amb una base física teòrica que hauria de ser compatible amb el motor
de física de Unity. No obstant això, a la pràctica no dóna el resultat esperat: el motor de física
no és capaç de contrarestar, amb la força centrípeta simulada, la força de la gravetat; en
comptes de simular una cable no elàstic d’una distància determinada, dóna la sensació que el
cable és molt elàstic o que rellisca i s’allarga, ja que el personatge cau lentament mentre es
balanceja.
Fig. 3.4.25 : Representació gràfica dels vectors gravetat (blau) i força centrípeta (vermell) a la vista de joc durant una simulació. Es pot notar que a la figura de la dreta, on la força centrípeta està més a prop de contrarestar la de la gravetat, la longitud del cable (negre) ha augmentat molt. Si la simulació fos exacta la força centrípeta cancel·laria la de la gravetat constantment per donar a lloc a un moviment circular on la longitud del cable (el radi) es manté constant.
Podem considerar, llavors, que aquest mètode no compleix els requeriments, i per tant queda
descartat.
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 70/101 Pau Montull i Jové
3.4.3.3.2 Aproximació al model real modificant la velocitat i afegint tensió (segon intent)
Tenint en compte que les forces del motor de física no són prou precises per simular aquests
moviments a partir de les fórmules convencionals, he decidit fer una aproximació al model
físic sense utilitzar-les. Tot i que no sigui tan fidel al model de moviment circular real:
Del model real extrapolo que el vector velocitat és tangencial al moviment i que, si el cable no
és elàstic, el cos es mou en unes trajectòries definides per la longitud del cable. Per tant:
- Consideraré que la velocitat del cos depèn només de l’acceleració de la gravetat (com fins
ara) i modifico lleugerament el seu vector director perquè sigui tangencial al moviment
circular:
- Crearé la funció “AddTension()” per afegir una força que resti a la de la gravetat en funció
de l’angle en que es troba el cos respecte el punt d’ancoratge i així restringir el moviment
del personatge a una esfera virtual determinada per la longitud del cable (radi), la
superfície de la qual representa les possibles trajectòries que podria prendre el
personatge gronxant-se del cable:
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 71/101 Pau Montull i Jové
En l’estat actual, el personatge és capaç de caminar, córrer, saltar, canviar la gravetat i
gronxar-se. Per tant podem considerar implementat el nivell de prioritat 1 del desglossament
de tasques.
3.4.4 NIVELL 2
3.4.4.1 Mecànica d’esprints i millores del controlador del personatge
Tot i que el controlador de personatge ja funciona correctament en l’entorn del joc en aquest
nivell de desenvolupament, encara s’hi poden fer uns ajustaments per optimitzar-lo i millorar-
lo.
La mecànica de gestió de velocitats d’esprint i de caminada permet al jugador moure’s a una
velocitat més elevada durant uns segons. L’ús que pot fer el jugador d’aquesta velocitat
d’esprint està limitat per el següent sistema lògic:
A més d’afegir aquesta mecànica de canvis de velocitats del personatge he millorat també la
funció de detecció del terra. L’original del “RigidbodyFPSWalker” comprovava si el component
de col·lisionador de càpsula del controlador estava en contacte amb algun altre objecte, per
tant si el personatge xocava amb algun objecte de l’escena, el programa entenia que estava
caminant damunt d’un terra. He modificat aquesta funció mitjançant el comandament
“Spherecast”, que projecta una esfera virtual molt poca distància per sota el límit inferior de la
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 72/101 Pau Montull i Jové
càpsula que representa el personatge; si topa amb algun objecte en fer-ho, dedueix que està
caminant per una superfície:
3.4.4.2 Mecànica de gestió del reinici del nivell
En alguns nivells del videojoc hi ha obstacles que el personatge ha d’evitar o altrament és
retornat a l’inici del nivell. La manera que té el joc de gestionar-ho és retornar el personatge
sobtadament a l’última porta d’entrada de nivell per la qual ha passat (reiniciant també la
gravetat del nivell). Es podria dir que quan el personatge mor en un nivell es reverteix el temps
al moment en que ell entrava en aquest nivell.
Per aconseguir aquest efecte crearé un objecte de joc buit per cada element que faci reiniciar
el personatge. Afegiré a aquests objectes de joc buits un component de col·lisionador de
capsa.
Crearé també un objecte de joc buit per cada porta d’entrada a un nivell, i afegiré un
component de col·lisionador pla. Seguidament col·locaré aquests objectes en una capa nova
anomenada “levelEnter” i els situaré al terra de cada entrada de nivell.
Ara modificaré el programa de controlador de personatge perquè gestioni aquest reinici del
nivell.
Faré servir un comandament d’”SphereCast” per determinar el moment en que el jugador
passa de nivell i anotar les condicions inicials d’aquest moment.
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 73/101 Pau Montull i Jové
Després mitjançant la funció “OnTriggerEnter” detectaré si el jugador ha interceptat un
element de reinici del nivell i en cas afirmatiu revertiré les condicions actuals a les inicials emmagatzemades anteriorment a les variables respectives:
3.4.4.3 Models de la pistola de gravitons i el dispositiu de ganxo extensible
Per fer els models de la pistola de gravitons i el dispositiu de ganxo extensible he fet servir
Maya:
Per la creació dels dos aparells he partit d’un objecte primitiu10 esfera situada a l’origen de
coordenades.
Fig. 3.4.26 : Primitiu esfera
Fig. 3.4.27 : Modelatge mitjançant l’eina d’escalatge i seleccionant les cares de l’esfera.
10 En l’àmbit del modelatge tridimensional s’anomena primitius els objectes geomètrics més bàsics com el cub, l’esfera, el cilindre, etc.
Fig. 3.4.28 : Eines utilitzades; d’esquerra a dreta i de dalt a baix, eina d’extrusió, d’annexió de polígons, de tall de cares, de tall en bucle de la figura, de combinació de vèrtexs, d’eliminació de vèrtexs, de suavització de la malla, de selecció, de selecció per forma lliure, de selecció per pintura, de moviment, de rotació i d’escalatge.
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 74/101 Pau Montull i Jové
Mitjançant les eines mostrades a la figura 3.3.28 he anat modelat l’esfera fins aconseguir les
formes de la pistola i el ganxo que es veuen a continuació:
Fig. 3.4.29 : Pistola de gravitons i dispositiu de ganxo extensible finalitzats.
3.4.5 NIVELL 3
3.4.5.1 Entorn gràfic del primer nivell del joc
La simplicitat del primer nivell del joc em permet crear-ne l’escenografia amb geometria
bàsica.
Començaré una escena de zero i faré les superfícies utilitzant objectes de cub escalats i els
alinearé per formar l’habitació seguint l’esquema del primer nivell que es pot trobar al GDD.
Fig. 3.4.30 : Superfícies del nivell 1 del joc creades a partir de la manipulació d’objectes geomètrics tridimensionals de tipus cub. Vista d’escena (esquerra) i vista de jerarquia (dreta).
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 75/101 Pau Montull i Jové
Per donar la sensació estètica que l’entorn està dibuixat aplicaré un material de “shader” dels
recursos estàndards de Unity anomenat “Toony-Lighted Outline”.
Seguidament Inseriré el personatge creat anteriorment a l’escena i afegiré dos objectes de
llum de tipus “punt de llum” i els repartiré més o menys uniformement per l’interior de la
cambra del nivell.
Fig. 3.4.31 : Carpeta de shaders de dibuixos del paquet de recursos estàndards de Unity.
Fig. 3.4.32 : Resultat de la incorporació de llums i shaders.
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 76/101 Pau Montull i Jové
Aquest nivell té un únic port de gravitons a la part superior, el qual representaré amb un altre
cub modificat que afegiré a la capa “gravitonPort” perquè es comporti com a tal.
Fig. 3.4.33 : Port de gravitons.
Finalment afegeixo el cursor per apuntar del centre de la pantalla com a objecte de joc
d’imatge bidimensional renderitzada directament a la imatge de l’objecte de joc de la càmera.
Fig. 3.4.34 : Vista del personatge aguantant la pistola de gravitons al nivell 1
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 77/101 Pau Montull i Jové
3.4.5.2 Creació del sistema de menús
Gràcies a l’última actualització de Unity (Unity 4.6), que conté un sistema d’edició
bidimensional d’interfícies d’usuari, la tasca de crear menús i interfícies gràfiques per al joc
serà molt més senzilla.
El sistema de creació d’interfícies gràfiques consta d’un seguit de components d’objecte de joc
que permeten crear menús d’objectes de joc bidimensionals basant-se en l’ordre jeràrquic en
que s’ordenen. Així subordinant dos objecte de joc bidimensional de tipus text a un de buit amb
un component de menú en disposició horitzontal, els dos quedaran distribuïts l’un al costat de
l’altre horitzontalment i ocupant tot l’espai de l’objecte de joc pare.
Usant aquests objectes de joc nous amb els seus components i important les imatges dels
menús representats al GDD (apartat 3.3.1.6) com a sprites, he recreat aquests menús en una
nova escena de Unity.
Fig. 3.4.35: Configuració d'importació d'un sprite bidimensional (en aquest cas l’element gràfic d’un botó) a la vista d’inspector.
Fig. 3.4.36: Resultat final de la importació de l'sprite de botó. També a la vista d'inspector.
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 78/101 Pau Montull i Jové
Fig. 3.4.37: Menú principal o de pausa
Fig. 3.4.38: Menú de controls
Fig. 3.4.40: Menú d'opcions Fig. 3.4.39: Llarga llista jeràrquica dels tres menús de la interfície d'usuari principal
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 79/101 Pau Montull i Jové
Després de crear els menús amb les seves jerarquies complexes per mantenir la relació
d’aspecte en qualsevol pantalla, he utilitzat els components de botó i de botó de
desplaçament per configurar les relacions entre menús, i he afegit animacions de transició
entre els menús:
Fig. 3.4.41: Mapa d'animacions de transicions d'un menú; l'estat per defecte es el buit, que posiciona el menú a la part visible de la pantalla, segons la variable "IsOpen" canviarà a l'estat obert o al tancat on es mostra el menú i s'amaga respectivament.
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 80/101 Pau Montull i Jové
Per gestionar aquestes animacions he creat aquest programa de javascript anomenat “menú”:
Finalment, per gestionar els canvis de menú i la transició entre el joc i els menús he fet aquest
segon programa de javascript anomenat “menuManager”:
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 81/101 Pau Montull i Jové
També he modificat el controlador de personatge perquè obri el menú en pressionar la tecla
[ESC]:
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 82/101 Pau Montull i Jové
4 CONCLUSIONS
Pel que fa a comprovar si un estudiant de batxillerat com jo pot desenvolupar un videojoc
funcional i com pot fer-ho, el balanç del treball és molt positiu: he descobert fent-lo que
malgrat la complexitat i la dificultat del procés, és possible i relativament senzill desenvolupar
un videojoc no professional gràcies a programes intermediaris com Unity.
Com ja s’avançava al començament del treball, el temps ha estat la limitació més gran. No
obstant això, en els pocs mesos de desenvolupament d’aquest treball, la part pràctica ha
avançat fins al punt d’obtenir un videojoc perfectament funcional. Del videojoc es podria dir
que està molt desenvolupat a un nivell purament tècnic i menys desenvolupat a nivell artístic.
Fixant-se en el desglossament de tasques que pretenia implementar a l’inici de la pràctica es
pot observar que només en faltaria implementar dues del tercer nivell. Considerant les
dificultats que he tingut en el curs del desenvolupament del joc, crec que l’abast era massa
ambiciós tot i no pretendre fer un videojoc complet. Tanmateix, també s’ha de tenir en compte
que s’acostuma a trigar un any com a mínim en desenvolupar un videojoc i que per un tema
logístic s’ha de desenvolupar primer bona part de les mecàniques de joc per poder centrar-se
en la part artística i per tant crec que és tota una fita que una sola persona de la meva edat i
sense cap pressupost econòmic pugui desenvolupar avui en dia un videojoc d’aquestes
característiques.
La implicació més important de l’assoliment d’aquesta fita és el fet que la tecnologia s’acosta
cada cop més a un públic més ampli i menys professional, i que això ha acostat els videojocs
a un sector de la producció que està interessat en el videojoc en sí, com a forma d’expressió o
com a forma d’entreteniment, però no necessàriament com a font d’ingressos.
Crec que la industria dels videojocs avança molt ràpidament cap a un mercat més lliure on els
qui fan els videojocs saben com fer-los perquè són els qui hi juguen. El primer avantatge
d’aquest mercat independent és el fet que hi ha molta més oferta, ja que els videojocs són
d’un pressupost mínim i per tant hi ha més estudis de desenvolupadors que poden permetre’s
fer-los. També és crucial per aquest nou mercat, l’aparició de plataformes de botiga online
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 83/101 Pau Montull i Jové
com Steam, que permeten una ràpida i senzilla distribució i que encoratgen als
desenvolupadors petits a publicar els seus jocs.
Respecte l’estudi del procés de desenvolupament dels videojocs m’agradaria emfatitzar la
gran importància d’una bona planificació; i és que, al contrari del que es podria pensar, sense
l’extensiva feina feta a la pre-producció, seria impensable produir un videojoc mínimament
complex.
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 84/101 Pau Montull i Jové
5 FONTS CONSULTADES
Autodesk Inc. (23 / 4 / 2014). 3D Animation Software, Computer Animation Software | Maya |
Autodesk. Recollit de 3D Animation Software, Computer Animation Software | Maya |
Autodesk: http://www.autodesk.com/products/maya/overview
Autodesk Inc. (17 / 3 / 2014). Digital Painting | 3D Painting | Sculpting Software | Mudbox .
Recollit de Digital Painting | 3D Painting | Sculpting Software | Mudbox :
http://www.autodesk.com/products/mudbox/overview
Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., . . . Thomas,
D. (2001). Manifest per al desenvolupament àgil de programari. Recollit de Manifest per
al desenvolupament àgil de programari:
http://agilemanifesto.org/iso/ca/manifesto.html
Bethke, E. (2003). Game development and production. Plano, Texas: Wordware Publishing, Inc.
Enciclopèdia Catalana, SAU. (30 / 10 / 2014). GDLC - videojoc. Recollit de diccionari.cat:
http://www.diccionari.cat/lexicx.jsp?GECART=0157953
Fristrom, J. (5 / 6 / 2013). Swinging Physics for Player Movement (As Seen in Spider-Man 2 and
Energy Hook) - Tuts+ Game Development Tutorial. Recollit de Swinging Physics for
Player Movement (As Seen in Spider-Man 2 and Energy Hook) - Tuts+ Game
Development Tutorial: http://gamedevelopment.tutsplus.com/tutorials/swinging-
physics-for-player-movement-as-seen-in-spider-man-2-and-energy-hook--
gamedev-8782
Let's Create A Game. (3 / 7 / 2013). Let's Create A Game - Resources. Recollit de Let's Create A
Game - Resources: http://letscreateagame.com/resources.html
Reallusion. (5 / 5 / 2012). What is IK/FK. Recollit de What is IK/FK:
http://www.reallusion.com/iclone/Help/iClone4/Std/08_Animation/Motion_Layer/Wh
at_is_IK_FK.htm
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 85/101 Pau Montull i Jové
TopTenREVIEWS. (15 / 12 / 2013). Autodesk 3ds Max 2014. Recollit de Autodesk 3ds Max
2014: http://3d-animation-software-review.toptenreviews.com/autodesk-3ds-max-
review.html
TopTenREVIEWS. (15 / 13 / 2013). Autodesk Maya 2014. Recollit de Autodesk Maya 2014:
http://3d-animation-software-review.toptenreviews.com/autodesk-maya-
review.html
Unify Community. (10 / 1 / 2012). FPSWalkerEnhanced - Unify Community Wiki. Recollit de
FPSWalkerEnhanced - Unify Community Wiki:
http://wiki.unity3d.com/index.php?title=FPSWalkerEnhanced
Unify Community. (7 / 5 / 2012). RigidbodyFPSWalker - Unify Community Wiki. Recollit de
RigidbodyFPSWalker - Unify Community Wiki:
http://wiki.unity3d.com/index.php?title=RigidbodyFPSWalker
Unity Tchnologies. (26 / 10 / 2014). Unity Scripting Reference. Recollit de Unity Scripting
Reference: http://docs.unity3d.com/ScriptReference/
Unity Technologies. (13 / 8 / 2011). Basic movement. Walking on walls. - Unity Answers. Recollit
de Basic movement. Walking on walls. - Unity Answers:
http://answers.unity3d.com/questions/155907/basic-movement-walking-on-
walls.html
Unity Technologies. (10 / 9 / 2014). Unity Manual. Recollit de Unity Manual:
http://docs.unity3d.com/Manual/index.html
Wikipedia, t. f. (19 / Octubre / 2014). Agile software development. Recollit de Agile software
development: http://en.wikipedia.org/wiki/Agile_software_development
Wikipedia, t. f. (9 / Octubre / 2014). Waterfall model. Recollit de Waterfall model:
http://en.wikipedia.org/wiki/Waterfall_model
Wikipedia, the free encyclopedia. (1 / 9 / 2014). Digital sculpting. Recollit de Digital sculpting:
http://en.wikipedia.org/wiki/Digital_sculpting
Wikipedia, the free encyclopedia. (29 / 5 / 2014). Polygonal modeling. Recollit de Polygonal
modeling: http://en.wikipedia.org/wiki/Polygonal_modeling
Wikipedia, the free encyclopedia. (21 / 10 / 2014). Skeletal animation. Recollit de Skeletal
animation: http://en.wikipedia.org/wiki/Skeletal_animation
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 86/101 Pau Montull i Jové
Wikipedia, the free encyclopedia. (31 / 10 / 2014). Subdivision surface. Recollit de Subdivision
surface: http://en.wikipedia.org/wiki/Subdivision_surface
Wikipedia, the free encyclopedia. (30 / 10 / 2014). Video game development. Recollit de Vide
game development: http://en.wikipedia.org/wiki/Video_game_development
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 87/101 Pau Montull i Jové
6 ANNEXOS
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 88/101 Pau Montull i Jové
6.1 Annex 1: Glossari tècnic
Videojoc: Joc interactiu en suport electrònic que pot ésser executat en un ordinador o en una
consola de joc, i en el qual l’usuari controla l’acció que es desenvolupa a la pantalla per mitjà
d’un teclat, d’un ratolí o d’una palanca de control.
Motor de Videojoc o Motor de Joc: Un motor de videojoc (o Game Engine en anglès) fa
referència a una aplicació de programari que permeten el disseny, la creació i la representació
del videojoc.
Originalment no existia cap separació entre els components que pertanyen al joc i els
components de programari bàsics que permeten el seu funcionament, és a dir que el que avui
en dia anomenem motor de joc era una part del joc, i estava barrejat amb les parts específiques
del joc. Amb l’evolució de les tècniques de desenvolupament de videojocs es va fer cada cop
més evident la divisió entre els components més tècnics i els més artístics del joc; ja que així
es podia aprofitar la base de programari d’un videojoc per fer-ne d’altres de semblants.
Els programes que avui anomenem motors de joc són plataformes de desenvolupament de
jocs que pretenen no condicionar de cap manera el videojoc que s’hi desenvoluparà, encara
que òbviament, les prestacions que ofereix cada motor el limitaran o l’encaminaran cap a uns
tipus de joc determinats.
Interfície gràfica d’usuari: La interfície gràfica d'usuari o GUI (acrònim en anglès de Graphic User
Interface) és una interfície d'usuari que utilitza elements gràfics, sonors i de control per
interaccionar de forma més intuïtiva amb un sistema informàtic que no pas el clàssic sistema
per línia d'ordres, més difícils d'aprendre i dominar.
Mecànica de Videojoc o Mecànica de Joc: Una mecànica de joc és una regla o conjunt de regles
que tenen per objectiu el produir una sèrie de resultats desitjables en un joc.
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 89/101 Pau Montull i Jové
Sprite: Un sprite és, als videojocs i en el context dels gràfics d’ordinador, un element gràfic que
es pot desplaçar sobre la pantalla. En principi, un sprite és parcialment transparent, i pot ser
animat (és a dir, és format de diversos mapes de bits que apareixen uns sobre els altres).
Shader: Els shaders es fan servir per realitzar transformacions i crear efectes especials com
il·luminació, foc o boira. La tecnologia de shaders és una tecnologia recent que ha
experimentat una gran evolució destinada a proporcionar al programador una interacció amb
la unitat de processament gràfic (GPU) fins ara impossible.
Rig: Mapa d’articulacions d’esquelet d’un model tridimensional. El rigging, la creació de mapes
d’articulacions associats als models tridimensionals de personatges virtuals, és un procés
complex que consisteix en donar un esquelet virtual que es pot articular com sigui necessari a
la malla tridimensional del model a animar.
Topologia: En el context de la indústria dels videojocs s’anomena topologia a la manera com
s' organitza la malla d'un model tridimensional.
Mapa d’UV: En el context dels gràfics d’ordinador, un mapa d’UV és la representació
bidimensional de les superfícies d’un model tridimensional. S’utilitzen els mapes d’UV per
aplicar textures als modes i adaptar-les a les seves formes.
Variable: En el marc de la programació informàtica, unitat d’emmagatzematge d’informació
que com el seu nom indica, pot variar durant l’execució d’un programa. Es pot emmagatzemar
en una variable informació de tot tipus, des d’un nombre decimal (quan és de tipus float) fins
a un vector tridimensional (si és de tipus “Vector3”), per exemple.
Funció, subrutina o subprograma: En el context de la programació informàtica, un sub-
algorisme que forma part de l'algorisme principal, el qual permet resoldre una tasca
específica.
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 90/101 Pau Montull i Jové
6.2 Annex 2: Programes complets
He citat al treball les parts més rellevants dels programes creats per al desenvolupament del
videojoc i n’he anat actualitzant l’estat. Tot i això, hi ha trossos que no he tingut temps
d’incloure o eren massa feixucs o evidents per afegir-los. Per tant per a possibilitar la
comprensió absoluta del funcionament dels programes creats els adjuntaré a continuació:
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 91/101 Pau Montull i Jové
6.2.1 RIGIDBODYFPSWALKER
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 92/101 Pau Montull i Jové
6.2.2 CONTROLADOR DE PERSONATGE (CAPSULECONTROLLER)
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 93/101 Pau Montull i Jové
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 94/101 Pau Montull i Jové
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 95/101 Pau Montull i Jové
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 96/101 Pau Montull i Jové
6.2.3 MECÀNICA DE GANXO EXTENSIBLE (GRAPPLINGSHOT)
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 97/101 Pau Montull i Jové
6.2.4 MECÀNICA DE CANVIS DE GRAVETAT (GRAVITYTARGET)
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 98/101 Pau Montull i Jové
6.2.5 MAPA D’ANIMACIONS DE CADA MENÚ (MENU)
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 99/101 Pau Montull i Jové
6.2.6 TRANSICIONS ENTRE MENÚS (MENUMANAGER)
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 100/101 Pau Montull i Jové
6.2.7 CANVIS DE QUALITAT DEL JOC (QUALITYCONTROL)
6.2.8 CANVIS DE VOLUM DEL JOC (VOLUMECONTROL)
Treball de Recerca Creació i Desenvolupament de Videojocs
nov.-14 101/101 Pau Montull i Jové
6.2.9 INDICADOR NUMÈRIC DEL BOTÓ DE DESPLAÇAMENT DEL
VOLUM (VOLUMEMETER)