Assistent per desenvolupar videojocs en Flash

Títol: Assistent per desenvolupar videojocs en Flash Volum: 1 Alumne: Joel Ortiz Ortiz Director/Ponent: Lluis Solano Albajes Departament: LSI Data: - Assistent per desenvolupar videojocs en Flash 2 Assistent per desenvolupar videojocs en Flash DADES DEL PROJECTE Títol del Projecte: Assistent per desenvolupar videojocs en Flash Nom de lʼestudiant: Joel Ortiz Ortiz Titulació: Enginyeria en Informàtica Crèdits: 37.5 Director/Ponent: Lluis Solano Albajes Departament: LSI MEMBRES DEL TRIBUNAL (nom i signatura) President: Daniela Tost Pardell Vocal: Friman Sánchez Castaño Secretari: LLuis Solano Albajes CALIFICACIÓ Calificació numèrica: Calificació descriptiva: Data: 3 Assistent per desenvolupar videojocs en Flash 4 Assistent per desenvolupar videojocs en Flash 1. Introducció! 12 1.1 Objectius del Projecte! 12 1.2 Context del Projecte: Videojocs! 13 1.2.1 Què és un videojoc?! 13 1.2.2 Classificació per gènere! 14 1.2.3 Classificació per plataforma! 22 1.3 Els Videojocs Flash! 24 1.3.1 Què és Flash?! 24 1.3.2 Característiques Principals! 25 1.4 Desenvolupament dels Videojocs Flash! 25 1.5 Precedents: Authorware! 26 2. Tecnologies Utilitzades! 27 2.1 Flash i ActionScript! 27 2.1.1 Flash! 27 2.1.2 ActionScript! 28 2.1.2.1 ActionScript Virtual Machine 2! 30 2.1.2.2 La nova API! 31 2.1.2.3 La Display List! 31 2.1.2.4 Control dʼesdeveniments unificat! 33 2.1.2.5 E4X XML! 34 2.1.3 Avantatges de Flash i ActionScript! 34 2.2 El llenguatge XML! 35 2.2.1 Què és XML?! 35 2.2.2 Estructura bàsica! 35 2.2.3 Avantatges del llenguatge XML! 36 2.3 Lʼentorn de treball! 37 2.3.1 Adobe Flash CS5! 37 3. Anàlisi de requeriments! 38 5 Assistent per desenvolupar videojocs en Flash 3.1 Usuaris del producte! 38 3.1.1 Categories! 38 3.1.2 Prioritats! 39 3.1.3 Participació! 40 3.2 Requeriments funcionals: Casos dʼús! 41 3.2.1 Crear una planificació! 41 3.2.2 Desar una planificació! 42 3.2.3 Carregar una planificació! 43 3.2.4 Afegir una activitat nova! 44 3.2.5 Editar les propietats dʼuna activitat! 45 3.2.6 Esborrar una activitat! 46 3.2.7 Afegir una transició nova! 47 3.2.8 Editar les propietats dʼuna transició! 48 3.2.9 Esborrar una transició! 49 3.2.10 Afegir condicions a una transició! 50 3.2.11 Previsualitzar la reproducció del joc! 51 3.2.12 Aturar una previsualització! 52 3.2.13 Començar partida! 52 3.3 Requeriments no funcionals! 54 3.3.1 Requeriments dʼaspecte (look & feel)! 54 3.3.1.1 Apariència atractiva! 54 3.3.1.2 Homogeneitat! 54 3.3.2 Requeriments dʼusabilitat! 55 3.3.2.1 Facilitat dʼús! 55 3.3.2.2 Navegació amb ratolí! 55 3.3.2.3 Control dʼerrors! 56 3.3.2.4 Sistema intuitiu! 56 3.3.2.4 Nom de la planificació! 56 6 Assistent per desenvolupar videojocs en Flash 3.3.3 Requeriments de rendiment! 3.3.3.1 Escalabilitat! 57 57 3.3.4 Requeriments operacionals i de lʼentorn! 3.3.4.1 Navegadors! 57 57 3.3.5 Requeriments de suport i manteniment! 58 3.3.5.1 Suport a lʼusuari! 58 3.3.6 Requeriments de seguretat! 58 3.3.6.1 Integritat de les dades! 58 3.4 Qualitat dels requeriments! 59 4. Especificació ! 60 4.1 Model de Casos dʼÚs! 60 4.1.1 Actors del sistema! 60 4.1.2 Diagrama de casos dʼús! 61 4.1.3 Especificació de casos dʼús! 62 4.1.3.1 Crear Planificació! 62 4.1.3.2 Desar Planificació! 63 4.1.3.3 Carregar Planificació! 63 4.1.3.4 Afegir Activitat! 63 4.1.3.5 Editar Activitat! 64 4.1.3.6 Esborrar Activitat! 64 4.1.3.7 Afegir Transició! 65 4.1.3.8 Editar Transició! 65 4.1.3.9 Esborrar Transició! 66 4.1.3.10 Previsualitzar! 66 4.1.3.11 Aturar Visualització! 66 4.1.3.12 Jugar! 67 4.2 Model Conceptual! 67 4.2.1 Diagrama de classes! 68 7 Assistent per desenvolupar videojocs en Flash 4.2.2 Descripció de les classes i els seus atributs! 69 4.2.2.1 Assistent! 69 4.2.2.2 Planificació! 69 4.2.2.3 Activitat! 70 4.2.2.4 Transició! 70 4.2.2.5 Reproductor! 70 4.2.2.6 Joc! 71 4.2.3 Descripció de les associacions! 71 4.2.3.1 Assistent-Planificació! 71 4.2.3.2 Planificació-Activitat! 72 4.2.3.3 Origen - Destí (Activitat-Activitat)! 72 4.2.3.4 Assistent-Reproductor! 73 4.2.3.5 Joc-Planificació! 73 5. Disseny! 74 5.1 Decisions de disseny! 74 5.2 El Model! 76 5.2.1 Patrons de disseny! 76 5.2.1.1 Patró Expert! 77 5.2.1.2 Patró Creador! 77 5.2.1.3 Patró Observador! 78 5.2.1.4 Patró Controlador! 78 5.2.2 Diagrama de classes de disseny ! 79 5.2.3 Model de dades! 80 5.3 Els Controladors! 81 5.4 Les Vistes! 81 5.4.1 El menú dinàmic! 82 5.4.1.1 Afegir activitat! 82 5.4.1.2 Editar activitat! 83 5.4.1.3 Editar transició! 84 8 Assistent per desenvolupar videojocs en Flash 5.4.1.4 Desar i carregar una planificació! 85 5.4.1.5 Previsualitzar! 86 5.4.2 Lʼàrea interactiva! 86 5.5 Realitzacions dels casos dʼús! 88 5.5.1 Crear planificació! 89 5.5.2 Desar planificació! 89 5.5.3 Carregar planificació! 90 5.5.4 Afegir activitat! 90 5.5.5 Editar activitat! 91 5.5.6 Esborrar activitat! 91 5.5.7 Editar transició! 92 5.5.8 Previsualitzar! 92 5.5.9 Aturar visualització! 93 6. Implementació ! 94 6.1 El mode edició: lʼassistent! 94 6.1.1 La classe flashAssistant! 95 6.1.1.1 Atributs importants! 95 6.1.1.2 Funcions importants! 96 6.1.2 La classe dynamicMenu! 97 6.1.2.1 Atributs importants! 97 6.1.2.2 Funcions importants! 98 6.1.3 La classe Board! 98 6.1.3.1 Atributs importants! 99 6.1.3.2 Funcions importants! 100 6.1.4 La classe Activity! 100 6.1.4.1 Atributs importants! 100 6.1.4.2 Funcions importants! 101 6.1.5 La classe Link! 102 9 Assistent per desenvolupar videojocs en Flash 6.1.5.1 Atributs importants! 102 6.1.5.2 Funcions importants! 103 6.1.6 La classe xmlPlayer! 104 6.1.6.1 Atributs importants! 104 6.1.6.2 Funcions importants! 105 6.2 El mode execució: el joc! 106 6.2.1 La classe Game! 106 7. Planificació temporal i anàlisi del cost! 107 7.1 Diagrama de Gantt! 107 7.2 Anàlisi del cost! 109 8. Conclusions ! 111 9. Bibliografia ! 113 10 Assistent per desenvolupar videojocs en Flash 11 Assistent per desenvolupar videojocs en Flash 1. Introducció En aquesta secció es posa al lector al context del projecte, es defineixen els objectius principals i sʼintrodueixen els conceptes necessaris per una millor i més completa comprensió de la memòria. 1.1 Objectius del Projecte Lʼobjectiu general dʼaquest projecte és aconseguir una aplicació gràfica interactiva senzilla que mostri el flux dʼexecució dʼuna aplicació Flash, composada per diferents fitxers de Flash, i permeti editar-lo per definir de forma interactiva la seqüència de transicions o nivells dʼun videojoc. Es podran definir quines són aquestes transicions i lʼordre de les fases permetent desfer les seqüències lineals habituals als videojocs. Es podran definir estructures on puguin existir diferents camins per arribar a un mateix punt i completar el joc de diferents maneres. Per assolir aquest objectiu sʼhan establert els següents objectius concrets: Dissenyar un producte software en Flash que faciliti la tasca dʼorganitzar i modificar les transicions entre les diferents activitats dʼun videojoc. Per aconseguir això cal: • Estudiar ActionScript 3, el llenguatge de programació de Flash. • Estudiar les necessitats que te un desenvolupador de videojocs Flash per tal dʼafegir totes les funcionalitats que calguin. • Adaptar els coneixements obtinguts a lʼenginyeria Informàtica de disseny de software al desenvolupament dʼuna eina pel desenvolupament de videojocs en Flash. Implementar el software fent servir Flash i ActionScript 3. Amb això volem aconseguir: • Dissenyar la interfície gràfica de lʼaplicació amb Flash dʼuna manera simple i intuïtiva per lʼusuari que permeti crear i modificar tots els elements dʼuna manera interactiva. 12 Assistent per desenvolupar videojocs en Flash • Minimitzar la necessitat per part de lʼusuari de lʼaplicació de tenir coneixements de Flash per utilitzar lʼeina per crear videojocs simples. Realitzar un videojoc senzill de demostració per mostrar les possibilitats de lʼeina. Escriure un tutorial per mostrar el funcionament de lʼaplicació i com es poden desenvolupar videojocs en Flash utilitzant aquest assistent. 1.2 Context del Projecte: Videojocs En aquest apartat es valoren els videojocs, es comenten les seves característiques bàsiques i una possible classificació per introduir-nos al context on està basat aquest projecte. 1.2.1 Què és un videojoc? Un videojoc és un software informàtic enfocat a lʼentreteniment que implica interacció del jugador, o usuari, amb una interfície dʼusuari que genera una reacció visual en un dispositiu de vídeo. Els dispositius electrònics que sʼutilitzen per jugar als videojocs es coneixen com a plataformes. Aquestes plataformes poden ser qualsevol dispositiu electrònic amb la capacitat dʼexecutar els videojocs. Algunes de les plataformes que tenim actualment són els ordinadors personals, les consoles, les màquines recreatives, les consoles portàtils, els telèfons mòbils o les PDAs. La història dels videojocs és molt recent encara. El primer videojoc conegut és Tennis for two, creat pel físic nord-americà William Higinbotham al 1957, que simulava un joc de tennis o ping pong a un oscil·loscopi. El va crear per a que els visitants del laboratori nacional de Brookhaven, on ell treballava, no sʼavurreixin. Higinbothan no va patentar el joc ja que no el va considerar com una gran diferència respecte de la capacitat existent dels ordinadors a lʼèpoca. El primer videojoc comercial no va aparèixer fins al 1971, bastants anys després. Es tractava de Computer Space, creat per Nolan Bushnell i Ted Dabney que 13 Assistent per desenvolupar videojocs en Flash després serien els fundadors dʼAtari, i va ser el primer videojoc que es va comercialitzar que funcionava amb monedes. Aquest joc va ser lʼinici de la nova indústria de lʼentreteniment als Estats Units, el Japó i Europa. Després de Computer Space, va aparèixer la primera consola de videojocs, Magnavox Odyssey, que utilitzava una televisió estàndard com a dispositiu de vídeo. Tot seguit, al 1972 i al 1975, respectivament van aparèixer les dues versions del famós videojoc Pong dʼAtari, la primera en versió arcade i la segona per jugar a casa. Lʼèxit comercial del Pong va provocar que moltes companyies desenvolupessin clons del joc i els seus propis sistemes de videojocs, engendrant així la indústria dels videojocs. La popularitat i rendibilitat dʼaquest tipus de software ha anat creixent amb el temps progressivament. Els videojocs han anat guanyant amb el temps amplitud del seu públic, varietat dels seus gèneres, i sofisticació tecnològica. Avui dia els videojocs tendeixen a imitar la realitat amb els seus gràfics en 3 dimensions, però també tenim jocs abstractes i jocs simples dʼentreteniment, tenim jocs per gent de totes les edats, per tots els gustos i pràcticament per qualsevol plataforma que sigui capaç dʼexecutar un videojoc. Per entrar més en detall sobre els tipus de videojocs que hi han, és necessari veure una classificació dels que existeixen actualment i ho farem de dues maneres: per gènere i per plataforma. En els següents apartats sʼanalitzen aquestes dues classificacions i es comenten les característiques de cada tipus de videojoc. 1.2.2 Classificació per gènere Els gèneres dels videojocs sʼutilitzen per categoritzar els jocs basant-se en el tipus dʼinteracció del jugador més que en diferències visuals o narratives. Els videojocs es classifiquen independentment del seu contingut o escenari, a diferència dʼaltres obres de ficció com els llibres o les pel·lícules. Per exemple, un videojoc dʼacció pertany a aquest gènere independentment de si es porta a terme a un món fantàstic o a lʼespai exterior. A cada gènere podem tenir subgèneres que delimiten les característiques del joc encara més acuradament. Encara no existeix una classificació consensuada dels videojocs però generalment els gèneres són els següents: Aventura: els videojocs dʼaventura es caracteritzen perquè el jugador ha dʼexplorar, investigar, solucionar trencaclosques, interaccionar amb altres personatges del videojoc i, sobretot, el joc té un enfocament en la trama 14 Assistent per desenvolupar videojocs en Flash argumental molt fort i sol tenir més importància que en altres tipus de videojocs. Aquest tipus de gènere pot englobar molts altres tipus de videojocs que també poden tenir una història treballada però només comentarem aquests subgèneres que són els jocs estrictament dʼaventures: • Aventura dʼacció: aquests videojocs combinen elements del gènere dʼaventures amb el gènere dʼacció i desafien al jugador tant en els seus reflexes com en la seva capacitat de resoldre problemes. És potser el gènere més variat de tots perquè inclou videojocs que podrien ser categoritzats en gèneres més específics. Exemples: Tomb Raider, The Legend of Zelda, Soul Reaver, God of War... Fig.1.1 The Legend of Zelda: Twilight Princess. 2006 • Aventura gràfica: la dinàmica dʼaquest tipus dʼaventures consisteix en anar resolent trencaclosques, plantejats com a situacions que succeeixen a la història, interactuant amb personatges o objectes que es van aconseguint durant el joc. Normalment les conversacions entre els personatges són una part important del joc i contenen diferents línies argumentals que depenen de les opcions que el jugador esculli als guions. Exemples: Day of the Tentacle, Maniac Mansion, Broken Sword, Monkey Island... Fig.1.2 Day of the Tentacle. 1993 15 Assistent per desenvolupar videojocs en Flash • Aventura conversacional: en aquest tipus dʼaventures es situa al jugador en un escenari descrit en text. El jugador ha dʼintroduir lʼacció a realitzar per teclat normalment en llenguatge natural. Lʼordinador interpreta lʼacció del jugador i això produeix una nova situació novament descrita en text, i així successivament. Aquest tipus dʼaventures ja no es veuen en occident ja que van evolucionar en aventures gràfiques però al Japó encara existeixen jocs dʼaquest tipus anomenats novel·les visuals. Exemples: Chichen Itza, Zork... Acció: en aquests jocs el protagonista ha de superar multitud dʼobstacles a base dʼutilitzar tot tipus dʼarmes. Es poden classificar en molts subgèneres que són: • First-Person Shooter (acció en primera persona): aquests jocs centren la seva jugabilitat al voltant de combats amb armes, normalment de projectils, des dʼuna perspectiva en primera persona. El jugador experimenta lʼacció a través dels ulls del protagonista i es mou per lʼescenari com si estigués dins del seu cos. Exemples: Quake, Doom, Counter Strike, Call of Duty... Fig.1.3 Quake 4. 2005 • Third-Person Shooter (acció en tercera persona): són jocs que basen la seva jugabilitat al voltant de combats amb armes igual que els anteriors però el jugador pot veure el personatge a la pantalla des dʼuna perspectiva en tercera persona. Exemples: MDK, Gears of War, Max Payne, Metal Gear Solid... • Matamarcians: potser és el subgènere més bàsic i antic dʼaquest gènere. Els jugadors han de controlar un personatge, normalment una 16 Assistent per desenvolupar videojocs en Flash nau espacial o similar, i disparar contínuament contra una gran quantitat dʼenemics alhora que intenta esquivar els seus atacs. Exemples: Space Invaders, Gradius, 1943: The Battle of Midway, R-Type... Fig.1.4 Gradius V. 2004 • Sobre rails: en aquest tipus de jocs el personatge del joc es mou per iniciativa pròpia sense que el jugador el controli. El jugador només té el control del arma i ha dʼanar apuntant i disparant contra els enemics. Exemples: The House of the Dead, Virtua Cop, Time Crisis... Estratègia: es caracteritzen per la necessitat del jugador de manipular un gran nombre de personatges, objectes o dades per aconseguir uns objectius pre-fixats. Normalment són jocs de temàtica bèl·lica però també hi han de gestió econòmica i social. Els podem classificar en dos subgèneres: • Estratègia en temps real: la principal característica dʼaquest jocs és que el temps transcorre de forma contínua i, per tant, els jugadors han de reaccionar als esdeveniments que succeeixen al moment. Exemples: Age of Empires, Warcraft, Command & Conquer, Starcraft... Fig.1.5 Starcraft II: Wings of Liberty. 2010 17 Assistent per desenvolupar videojocs en Flash • Estratègia per torns: a diferència dels anteriors, en aquests jocs, cada jugador te un torn per jugar i no pot fer res mentre els altres jugadors estan al seu torn. Exemples: Civilization, Worms, Warlords, Heroes of Might and Magic... Lluita: en aquest cas es tracta de jugar amb un personatge lluitador utilitzant tècniques de combat, poders màgics o donant cops. Tenim tres subgèneres: • Lluita un contra un: es tracta simplement de lluitar contra un altre lluitador i tractar de guanyar i evitar que ens guanyi. Exemples: Street Fighter, The King of Fighters, Soul Calibur, Mortal Kombat... Fig.1.6 Street Fighter IV. 2008 • Beatʼem up: en aquests jocs també portem un personatge lluitador però a diferència dels anteriors haurem de lluitar amb un gran nombre dʼenemics mentre avancem per un nivell llarg. Exemples: Golden Axe, Final Fight, Streets of Rage, Double Dragon... • Free for all: aquesta modalitat normalment és multi-jugador i guanya el jugador que més enemics mata o el primer que mata un nombre dʼenemics pre-establert. Exemples: Super Smash Bros... Plataformes: es caracteritzen perquè el jugador ha de caminar, saltar o escalar per una serie de plataformes i penya-segats, amb enemics, mentre es recullen objectes per aconseguir completar el joc. És un gènere que va ser creat en els anys 80 però encara és molt popular en la actualitat. Exemples: Super Mario Bros, Sonic the Hedgehog, Megaman, Castlevania... 18 Assistent per desenvolupar videojocs en Flash Fig.1.7 Sonic the Hedgehog 4. 2010 Rol: aquest gènere sʼinspira en els jocs de rol clàssics, on el protagonista interpreta un paper i ha de millorar les seves habilitats mentre interactua amb lʼentorn i altres personatges. També és habitual que succeeixi que les decisions que pren el teu personatge influeixen directament en el seu futur pròxim. Hi han diversos subgèneres que es poden englobar en aquesta categoria: • Vista en tercera persona: la seva jugabilitat està basada en els jocs de rol i el jugador pot veure el seu personatge des dʼuna perspectiva en tercera persona, segurament són els més comuns. Exemples: Baldurʼs Gate, Fable, Final Fantasy, Neverwinter Nights... Fig.1.8 Baldurʼs Gate II: Shadows of Amn. 2000 • Vista en primera persona: són videojocs amb una jugabilitat exactament igual que els anteriors però el personatge es veu des dʼuna perspectiva en primera persona. Exemples: Fallout, The Elder Scrolls: Oblivion, Eye of the Beholder, Bardʼs Tale... 19 Assistent per desenvolupar videojocs en Flash • Videojocs de rol massiu (MMORPG): permeten a milers de jugadors accedir a un món virtual de manera simultània a través dʼInternet. Consisteix en crear un personatge del qual podrem escollir raça, professió, armes, etc. Després el personatge sʼintrodueix al joc i pot anar millorant les seves habilitats lluitant amb altres personatges del joc o realitzant missions. Exemples: Ragnarok Online, Everquest, Lineage, World of Warcraft... Fig.1.9 World of Warcraft: Wrath of the Lich King. 2010 • Rol dʼacció: tenen les mateixes característiques que els altres videojocs de rol però, a diferencia dʼaltres tipus de jocs de rol, ofereixen uns combats en temps real molt més realistes, per tant, és més important lʼacció que la estratègia. Exemples: Harry Potter, Silver, Kingdom Hearts, Diablo... • Rol tàctic: es caracteritzen per tenir alhora elements dels videojocs de rol i dels dʼestratègia. Generalment el jugador controla un grup de personatges que han dʼanar superant combats dʼestratègia però també els personatges poden pujar de nivell, poden equipar-se amb objectes i hi ha una història que pot variar segons les accions dutes a terme pel grup. Exemples: Sonic Chronicles, Ogre Battle, Final Fantasy Tactics, Fire Emblem... Musicals: la jugabilitat dʼaquests jocs està orientada significativament, o fins i tot totalment, a la interacció del jugador amb la música. Hi han dʼimitar cantants, simulació dʼinstruments o dʼaltres en els que sʼutilitzen els ritmes de la música per la mecànica del joc. Exemples: Singstar, Guitar Hero, Pump It Up, Elite Beat Agents... 20 Assistent per desenvolupar videojocs en Flash Esportius: aquest gènere engloba tots els videojocs que basen la seva jugabilitat en qualsevol esport, ja sigui simulat o dʼuna manera més arcade. Exemples: Pro Evolution Soccer, Wii Sports, Mario Tennis, Tony Hawkʼs Pro Skater... Fig.1.10 Pro Evolution Soccer 2011. 2010 Curses: la característica principal dʼaquests jocs es que intenten imitar competicions entre vehicles. Normalment lʼobjectiu és recórrer una certa distància en el menor temps possible però poden haver altres variants. Exemples: Mario Kart, F-Zero, Gran Turismo, Need for Speed... Simulació: aquest gènere involucra al jugador en una situació simulada determinada, on lʼobjectiu és que la simulació sigui el més realista possible. Hi han simulacions molt diferents i variades, des de la simulació de la vida dʼuna persona fins a la conducció dʼun avió. Exemples: Microsoft Flight Simulator, Los Sims, SimCity, RollerCoaster Tycoon... Fig.1.11 Sim City 4. 2003 21 Assistent per desenvolupar videojocs en Flash Puzle: se centren en desafiaments per a la ment, encara que a vegades els jocs afegeixen límit de temps o altres elements dʼacció. Encara que molts jocs dʼaventures i dʼacció tenen trencaclosques com a part del joc, un autèntic joc de puzle centra la seva jugabilitat principal en la resolució de puzles. Exemples: Portal, World of Goo, Tetris, Profesor Layton y la Villa Misteriosa... Educatiu: aquests tipus de videojocs no es caracteritzen pel seu tipus de jugabilitat com la majoria dels altres, sinó pel seu objectiu, per tant, la seva jugabilitat pot ser qualsevol de les anteriors. La seva característica principal es que volen aconseguir que el jugador adquireixi algun tipus de coneixement. Estan dirigits per a totes les edats, no només per a nens, encara que siguin els més habituals. Exemples: English Training, Art Academy, Big Brain Academy... 1.2.3 Classificació per plataforma El terme “plataforma” en el món dels videojocs fa referència a una combinació específica de maquinari que, juntament amb el seu corresponent programari de baix nivell, permet a un videojoc funcionar correctament. Es pot fer una classificació pel tipus de plataforma en la qual funciona un videojoc, ja que és habitual que hi hagin diferents tipus de jocs segons la plataforma en la qual funcionen. Tot i això, és també bastant comú que hi hagin videojocs que existeixen per diverses plataformes alhora, per tant, el fet que un joc pertanyi a una categoria no vol dir que no pugui estar també en les altres. Aquestes són les principals plataformes que sʼutilitzen per jugar als videojocs: Màquina recreativa: són màquines grans dʼentreteniment que funcionen mitjançant monedes, normalment situades en negocis públics com els restaurants, salons recreatius, centres comercials, pistes de bitlles, etc. Consola de joc: són computadores dʼentreteniment interactiu que produeixen un senyal de video que pot ser utilitzat per qualsevol dispositiu de sortida (televisió, monitor, projector...) per reproduir un videojoc. La diferència principal amb els ordinadors és que les consoles són creades exclusivament per lʼutilització de videojocs. 22 Assistent per desenvolupar videojocs en Flash Consola Portàtil: són dispositius electrònics lleugers que permeten jugar a videojocs. La diferència principal amb les altres consoles és que els controls, els parlants i la pantalla són tots parts de la mateixa unitat. Telèfon Mòbil, PDAs, o similars: els videojocs disenyats per aquests dispositius es diferencien dels altres perque són disenyats per utilitzar les tecnologies que incorporen aquests aparells. El primer videojoc que es va instal·lar a un telèfon mòbil va ser el de la serp dels models de Nokia del 1997 i es va convertir en el videojoc més jugat del planeta. En Línia: avui dia podem considerar la xarxa dʼInternet com a una altra plataforma on es desenvolupen videojocs, on els propis navegadors sʼencarreguen dʼoferir als usuaris entreteniment, so i vídeo gràcies a les tecnologies de Java i Flash. Els jocs en línia poden ser de qualsevol tipus, des de jocs basats en text fins a jocs que incorporen gràfics complexes en tres dimensions que representen mons virtuals poblats per molts jugadors que juguen simultàniament. Ordinadors: aquesta plataforma és similar a les consoles de joc en quant als tipus de jocs que incorporen. De fet, podríem considerar lʼordinador una plataforma que incorpora alhora jocs dels tipus de màquines recreatives, altres de consoles, i molts jocs en línia. Encara que també hi han alguns jocs que només es poden trobar als ordinadors i darrerament les consoles de jocs també incorporen jocs en línia. 23 Assistent per desenvolupar videojocs en Flash 1.3 Els Videojocs Flash Amb les classificacions anteriors ja es pot obtenir una idea bastant clara dels tipus de videojocs que existeixen a lʼactualitat, i de tots aquests videojocs, hi ha un tipus en el qual es centra aquest projecte: els videojocs Flash. En aquest apartat explicaré més en detall què són aquests videojocs. 1.3.1 Què és Flash? Flash és una plataforma multimèdia creada per la companyia Adobe que sʼutilitza per afegir vídeo, animació i interactivitat a les pàgines web. Darrerament ha guanyat molta popularitat i sʼutilitza habitualment per fer anuncis publicitaris a Internet i jocs en línia que els propis navegadors poden mostrar sense necessitat de software addicional. El contingut de les aplicacions Flash es pot mostrar en diversos sistemes operatius dʼordinadors i altres dispositius electrònics, com ara els telèfons mòbils. Només és necessari tenir instal·lat lʼAdobe Flash Player que és gratuït i està disponible per als navegadors dʼInternet més comuns i per altres dispositius. Això facilita la tasca pels desenvolupadors ja que un joc Flash es pot utilitzar pràcticament des de qualsevol ordinador i molts telèfons mòbils actuals. Els videojocs Flash, per tant, són normalment videojocs en línia, pensats per ser jugats a Internet, que contenen animació i interactivitat amb lʼusuari. Per tant, poden pertànyer a pràcticament qualsevol dels gèneres que existeixen i poden ser utilitzats en multitud de plataformes. Això fa que sigui molt avantatjós utilitzar aquesta tecnologia. Fig.1.12 jocs Flash 24 Assistent per desenvolupar videojocs en Flash 1.3.2 Característiques Principals En resum, aquestes són les característiques principals dels videojocs Flash, les quals es poden aplicar també a les aplicacions Flash en general: Engloben pràcticament tots els gèneres de videojocs, per tant, podem trobar moltes i molt diferents aplicacions Flash. Poden funcionar en diferents plataformes diferents encara que el seu objectiu principal és funcionar com aplicacions o videojocs en línia degut a la facilitat dels navegadors web dʼexecutar-los. Contenen principalment interactivitat amb lʼusuari i animacions, encara que també poden incorporar so i vídeo. La quantitat de cadascun dʼaquests elements variarà segons el tipus dʼaplicació. Per exemple, els videojocs Flash tenen una gran quantitat dʼanimacions i interactivitat, en canvi una aplicació segurament contindrà poques animacions. 1.4 Desenvolupament dels Videojocs Flash El desenvolupament dels videojocs és un procés molt delicat i elaborat. Igual que amb qualsevol altre software, la planificació és molt important per a un bon funcionament del joc. I precisament dʼaixò tracta aquest projecte, de fer una eina que faci més fàcil la planificació dels nivells que conté un videojoc o una aplicació Flash. Segurament en qualsevol altre entorn aquesta eina no tindria gaire sentit, però tractant-se de videojocs Flash, on podem crear animacions simples amb molta facilitat, el planificador estalvia la feina de programació que caldria per fer el joc complet. Lʼeina no estarà orientada per desenvolupadors que coneguin i disposin de lʼentorn de desenvolupament de Flash, sinó per a que qualsevol persona que disposi de petites aplicacions o animacions Flash o que sàpiga com crear-les, pugui planificar lʼexecució de certa manera per a que constitueixi un conjunt, esdevenint dʼaquesta manera un joc complet o aplicació completa. Dʼaquesta manera es permet a 25 Assistent per desenvolupar videojocs en Flash usuaris inexperts la possibilitat de crear petits videojocs simples a partir de les seves animacions. En resum, amb aquesta eina podrem fer els nivells o activitats diferents de lʼaplicació per separat sense tenir en compte el joc en conjunt, i després el planificador ens ajudarà a crear lʼestructura final. Tot dʼuna manera gràfica i interactiva per facilitar la tasca als usuaris més inexperts. 1.5 Precedents: Authorware Per entendre una mica millor el funcionament de la eina per planificar activitats en Flash, sʼexplicarà una altra aplicació ja existent que funcionava de manera similar per aconseguir propòsits diferents, ja que no es tractava dʼun programa relacionat amb Flash ni amb els videojocs. Authorware és un software de programació gràfic, inicialment creat per permetre als usuaris crear aplicacions senzilles per ensenyament a distància. El programa funciona mostrant per pantalla el diagrama de flux de lʼaplicació final. Lʼusuari pot afegir, text, imatges, so i vídeo; fer-lo interactiu i afegir elements de navegació com enllaços, botons, i menús. També disposa dʼun llenguatge de programació per usuaris avançats que permet afegir lògica a les transicions entre els diversos estats de lʼaplicació i afegir funcions complexes. Lʼobjectiu del projecte és aconseguir una aplicació gràfica interactiva senzilla que mostri el flux dʼexecució dʼuna aplicació Flash i permeti editar-lo, mostrant totes les activitats i les transicions entre elles. Per tant, lʼestructura que utilitza Authorware és molt similar encara que el seu propòsit sigui totalment diferent. En aquest cas el programa mostrarà el diagrama de flux del videojoc o aplicació final, i lʼusuari podrà modificar lʼordre dʼexecució dʼuna manera gràfica i intuïtiva. A més a més, es podran afegir condicions a les transicions. Com ja sʼha esmentat abans, per afegir condicions i lògica a les aplicacions cal utilitzar un llenguatge de programació, per això, i per no complicar la usabilitat de lʼaplicació per la resta dels usuaris, aquesta opció estarà limitada per aquells usuaris que siguin capaços dʼafegir codi a les seves activitats. 26 Assistent per desenvolupar videojocs en Flash 2. Tecnologies Utilitzades En aquesta secció de la memòria es descriuen les tecnologies utilitzades per desenvolupar aquest projecte. Aquestes tecnologies són bàsicament lʼentorn de desenvolupament de Flash i el seu llenguatge de programació: lʼActionScript, i el llenguatge XML. Es valoraran les seves característiques i es comentarà els ventatges i desventatges que hi ha a lʼhora dʼutilitzar aquestes tecnologies. Al final de la secció es valorarà lʼentorn de treball on sʼha desenvolupat el projecte. 2.1 Flash i ActionScript 2.1.1 Flash Abans ja sʼha fet una breu introducció sobre aquesta tecnologia per poder explicar conceptes importants a la introducció, ara sʼaprofundirà en el tema per esmentar tots els aspectes tècnics que cal explicar per entendre què ens permet aconseguir Flash. Flash va ser creada per la companyia Macromedia (que després es va fusionar amb la companyia Adobe) lʼany 1996. El seu nom te com a origen un software previ anomenat FutureSplash Animator, que va ser adquirit per Macromedia i reanomenat Flash, que és la fusió de les paraules “Future” i “Splash”. Flash proporciona als usuaris una interfície gràfica que permet crear fàcilment animacions o aplicacions, ja que es pot afegir codi a les animacions per afegir comportaments complexos. Aquestes aplicacions sʼexecuten amb el software gratuit Flash Player que sʼha esmentat a la introducció. Flash Player permet executar els fitxers amb extensió .swf (ShockWave Flash). Aquests fitxers es poden crear mitjançant lʼeina de desenvolupament Adobe Flash, lʼeina de desenvolupament de codi lliure Adobe Flex i també altres aplicacions. Els fitxers són anomenats generalment pel·lícules flash i poden contenir animacions, videojocs i altres aplicacions. Al principi el seu propòsit principal va ser la creació dʼanimacions per web, però amb el temps la plataforma ha anat creixent i la companyia Adobe ha enfocat lʼeina cada vegada més al desenvolupament de software, per tant, ara es poden fer 27 Assistent per desenvolupar videojocs en Flash aplicacions complexes i videojocs per Internet. Per poder fer aplicacions i videojocs amb Flash cal utilitzar el llenguatge de programació associat, que sʼanomena ActionScript. Aquest llenguatge ha evolucionat molt i ara mateix permet fer aplicacions molt potents i ens ofereix alguns avantatges. A continuació sʼexplica lʼActionScript i sʼestudien els seus avantatges i característiques principals. 2.1.2 ActionScript ActionScript és un llenguatge de programació orientat a objectes originalment desenvolupat per Macromedia i després evolucionat per Adobe una vegada fusionades ambdues companyies. Es basa en les especificacions estandarditzades de la ECMA sobre llenguatges dʼscripting, que significa que té la mateixa semàntica i sintaxi que un altre llenguatge més conegut anomenat JavaScript, molt utilitzat en lʼàmbit web. ActionScript sʼutilitza principalment per al desenvolupament de pàgines web i software relacionat amb la plataforma dʼAdobe Flash Player. El llenguatge en si és de codi lliure i la seva especificació sʼofereix de manera gratuïta i hi han disponibles un compilador i una màquina virtual de codi lliure. Lʼespecificació de la ECMA està definida com a estàndard ISO/IEC 16262 i estableix unes característiques molt concretes per als llenguatges que la segueixen. Són les següents: Els tipus sʼassocien amb valors, no amb variables, per tant, les variables poden canviar el seu valor dinàmicament. El comportament de la variable defineix el seu tipus i no al contrari. Es treballa en un entorn en temps dʼexecució. Les funcions són objectes, per tant, es poden crear funcions dinàmicament en temps dʼexecució. Són llenguatges orientats a objectes. 28 Assistent per desenvolupar videojocs en Flash ActionScript utilitza aquestes característiques definides a lʼespecificació de la ECMA i les amplia. Originàriament es va dissenyar per al control de simples animacions vectorials 2D realitzats en Macromedia Flash. Inicialment centrades en lʼanimació, les primeres versions de Flash oferien molt poques opcions dʼinteractivitat i, per tant, havia una capacitat de programació molt limitada. Posteriorment, quan Adobe va comprar Macromedia, es va canviar lʼenfocament cap a lʼenginyeria del software, per tant, les darreres versions del llenguatge afegeixen funcionalitat que permet la creació de videojocs basats en web, aplicacions complexes dʼInternet, i altres aplicacions més avançades. La primera versió del llenguatge va aparèixer amb el llançament de Flash 5 al setembre de 2000, on les accions de Flash 4 es van millorar i es van anomenar “ActionScript” per primera vegada. Aquesta va ser la primera versió amb influències de JavaScript i lʼestàndard ECMA-262, seguint el seu model dʼobjectes i molts dels seus tipus de dades bàsiques. El canvi va ser molt gran. Es podien declarar variables, crear funcions definides per lʼusuari amb pas de paràmetres i retorn de valors, i també es podia editar lʼActionScript amb un editor de text en lloc dʼescollir accions en un quadre de diàleg. La següent gran evolució del llenguatge, ActionScript 2.0, es va introduir al setembre de 2003 amb el llançament de Flash MX 2004 i el seu corresponent lector, Flash Player 7. Com a resposta de la demanda dels usuaris dʼun llenguatge millor equipat per aplicacions més grans i més complexes, ActionScript 2.0 incorpora control de tipus en temps de compilació i sintaxi basada en classes. Aquesta nova versió també incorpora herència de classes, així els programadors podien crear classes i interfícies, tal i com es faria als llenguatges basats en classes com Java o C++. Encara que això permetia una programació més estructurada i orientada a objectes, el codi encara es compilava al codi de bytes dʼActionScript 1.0, permetent dʼaquesta manera utilitzar-lo en versions anteriors de Flash Player. Al juny de 2006, va debutar ActionScript 3.0 amb Adobe Flex 2.0 i el seu lector corresponent, Flash Player 9. Aquesta nova versió és una reestructuració fonamental del llenguatge, tant és així, que utilitza una màquina virtual totalment diferent. Flash Player 9 conté dues màquines virtuals, AVM1 pel codi escrit en ActionScript 1.0 i 2.0, i AVM2 pel codi escrit en ActionScript 3.0. A la següent secció es comenten les principals característiques de lʼActionScript 3.0. 29 Assistent per desenvolupar videojocs en Flash A la nova versió dʼActionScript hi ha una gran quantitat de millores. A continuació es comenten algunes de les millores més importants i que sʼhan considerat importants per aquest projecte. La nova màquina virtual. La nova API. La Display List. Control dʼesdeveniments unificat. El nou tractament dels XML (E4X) 2.1.2.1 ActionScript Virtual Machine 2 Per a la nova versió dʼActionScript, Adobe va dissenyar una nova màquina virtual anomenada ActionScript Virtual Machine 2 (AVM2) amb lʼobjectiu de millorar el rendiment de les aplicacions creades amb aquest llenguatge de programació. Un dels motius de la millora del rendiment és el nou compilador que incorpora la màquina virtual, que compila el codi primer a un bytecode intermedi a mig camí entre el llenguatge de programació que utilitzen els usuaris i el codi màquina natiu. Després, en temps dʼexecució, un altre compilador de tipus JIT (Just in Time) tradueix aquest bytecode al codi màquina de forma dinàmica. La millora del rendiment de les aplicacions executades amb lʼAVM2 es produeix perquè és molt més ràpid traduir el bytecode intermedi a codi màquina que no fer la traducció directament des de el codi dʼalt nivell. Sʼha de tenir en compte però, que amb aquest canvi de màquina virtual, no podem barrejar codi dʼActionScript 2.0 amb codi dʼActionScript 3.0 ja que no són compatibles, encara que el Flash Player és capaç dʼexecutar aplicacions fetes amb qualsevol versió dʼActionScript perquè incorpora lʼAVM1 i lʼAVM2. 30 Assistent per desenvolupar videojocs en Flash 2.1.2.2 La nova API LʼAPI (Application Programming Interface) de Flash Player és un conjunt de classes i funcions que posen les capacitats de Flash Player al servei del llenguatge ActionScript. Aquesta funcionalitat és el pont entre el nucli del llenguatge ActionScript i la resta de la plataforma. És la font de gran part de la potència disponible a les aplicacions Flash i és un complement molt important. La nova API de Flash inclou un munt de noves característiques que només es pot utilitzar a través dʼActionScript 3.0. Aquestes inclouen el tractament molt més fàcil del llenguatge XML a través de E4X, capacitats més avançades per manipular la llista de visualització o la manipulació avançada dʼimatges amb filtres. La nova API de Flash proporciona al desenvolupador eines molt útils a lʼhora de fer aplicacions com la que es vol fer en aquest projecte. Entre dʼaltres, podem trobar gestió dʼesdeveniments i recuperació dʼinformació de teclat i ratolí, mostrar informació gràfica, càrrega dʼarxius externs... Moltes gestions bàsiques necessàries a molts tipus dʼaplicacions que ja estan fetes i el desenvolupador pot utilitzar i ampliar al seu gust. 2.1.2.3 La Display List A la nova versió dʼActionScript es permet lʼaccés directe a la display list de Flash en temps dʼexecució. Per entendre el concepte dʼaccedir a aquesta llista de visualització, cal entendre en què consisteix la display list de Flash. Les aplicacions programades amb ActionScript 3.0 tenen una jerarquia dels objectes que es mostren per pantalla coneguda com a display list. Aquesta jerarquia es crea amb relacions pare-fill entre els objectes visibles de lʼaplicació. Algunes parts de la jerarquia es creen automàticament, mentre que dʼaltres es poden crear mitjançant funcions dʼActionScript. Tots els elements visibles de lʼaplicació estan continguts en aquesta jerarquia, i poden ser de diferents tipus. Un dʼaquests elements és lʼstage, que fa referència al contenidor principal de lʼaplicació i està al nivell més alt de la jerarquia. Aquest contenidor és el pare de tots els altres objectes que hi han a la jerarquia. Lʼstage es crea automàticament quan la pel·lícula Flash sʼexecuta al Flash Player. Cada aplicació té un i només un objecte de tipus stage que té com a fill la línia de temps principal de lʼaplicació. 31 Assistent per desenvolupar videojocs en Flash La resta dʼelements visibles de lʼaplicació penjen de lʼstage a la jerarquia i poden ser de tres tipus. Display Object: tots els elements visibles que hi han a les aplicacions dʼActionScript 3.0 són display objects, per tant, no podem afegir a la display list cap objecte que no sigui dʼaquest tipus. Per exemple, no podem afegir a la display list una variable de tipus Number. Interactive Object: aquests objectes són una subclasse dels display objects. Es diferencien dels anteriors perquè poden rebre esdeveniments i respondre. Per exemple, un botó seria un tipus de interactive object. Display Object Container: per últim tenim aquests objectes que són subclasse dels anteriors i es diferencien dʼells perquè a més de tenir les capacitats dʼun interactive object, també tenen la capacitat de contenir altres display objects. Per exemple, lʼstage és un tipus de display object container. Fig.2.1 Jerarquia de classes de Display Object 32 Assistent per desenvolupar videojocs en Flash 2.1.2.4 Control dʼesdeveniments unificat El control dʼesdeveniments es va canviar totalment amb la nova versió dʼActionScript. El nou model de control dʼesdeveniments es basa en el nivell 3 de lʼespecificació dʼesdeveniments del Document Object Model (DOM). Encara que els fitxers SWF no sʼhadereixen específicament a lʼestàndard DOM, hi ha prou similituds entre la display list i lʼestructura del DOM perquè lʼaplicació del model dʼesdeveniments sigui possible. Per entendre millor la importància dʼaquest concepte cal explicar una mica de què sʼestà parlant. Un sistema de control dʼesdeveniments es compon de tres components principals: els llençadors (event dispatchers), els oients (event listeners), i els objectes esdeveniment (event objects). Els llençadors dʼesdeveniments són objectes que distribueixen esdeveniments als objectes que estan registrat com a oients. Fig.2.2 Diagrama UML del sistema dʼesdeveniments. Quan un llençador invoca una sol·licitud per llençar un esdeveniment, es crea un objecte esdeveniment i es distribueix cap a tots els objectes oients dʼaquest tipus dʼesdeveniment concret. A continuació aquests objectes oients poden extreure informació, ja sigui de lʼobjecte esdeveniment (dades enviades del llençador als oients) o directament de lʼobjecte llençador (dades que agafen els oients del llençador). Qualsevol de les dues opcions dʼaconseguir informació per part dels oients és igual de bona i capaç de donar als oients tota la informació que necessita. Escollir una o altre es deixa a discreció de qui desenvolupa el llençador. Els esdeveniments més importants a lʼhora de crear una aplicació són els esdeveniments de ratolí, ja que tenim que capturar en tot moment el que està fent lʼusuari a la finestra de lʼaplicació. 33 Assistent per desenvolupar videojocs en Flash 2.1.2.5 E4X XML Un dels principals canvis en ActionScript 3.0 és la forma de tractar el contigut XML. Mentre que sʼhan heretat una gran quantitat de similituds de la versió 2.0 dʼActionScript, hi ha nous mètodes dʼestalvi de temps a lʼhora de tractar amb XML que fan que treballar amb aquest tipus dʼarxius sigui molt més fàcil. Una de les prestacions és ECMAScript per a XML, coneguda com E4X per abreujar. Un dels avantatges més important és que ara sʼidentifica un document XML com un objecte més al codi dʼActionScript. Una variable de de la classe XML que representa al document i que ens proporciona la funcionalitat bàsica necessària per manipular i accedir a la informació guardada en un fitxer XML. Aquest tractament dels XML que ens ofereix Flash i ActionScript és molt important per desenvolupar aquest projecte ja que necessitarem guardar la informació planificada pels usuaris a lʼaplicació per després poder-la executar, i precisament utilitztarem el llenguatge XML per fer això. 2.1.3 Avantatges de Flash i ActionScript Interfície gràfica: per desenvolupar aquesta aplicació, un dels objectius era fer-ho de forma interactiva i gràfica per a que els usuaris puguin treballar dʼuna manera intuïtiva. Flash ens facilita aquesta feina ja que incorpora un munt dʼutilitats per afegir animacions i interactivitat a les aplicacions. Gestió dʼesdeveniments: la interacció amb lʼusuari és un concepte molt important en qualsevol aplicació, i lʼAPI de Flash ens proporciona tota la funcionalitat feta per gestionar els esdeveniments de ratolí i teclat. E4X XML: com ja sʼha comentat a la secció anterior, necessitem una manera de comunicar lʼaplicació que planifica els videojocs amb el joc que després sʼexecutarà, i la nova versió dʼActionScript incorpora funcionalitats per tractar XML que facilitarà molt aquesta feina. Compatibilitat i accesibilitat: les aplicacions Flash es poden executar en qualsevol sistema operatiu i qualsevol navegador web existent. A més a més, són molt accessibles per a qualsevol usuari ja que no requereixen gaires 34 Assistent per desenvolupar videojocs en Flash recursos de hardware per ser executades. També sʼha de tenir en compte que aquest projecte tracta principalment sobre planificar la creació de videojocs Flash, i aquesta és la tecnologia més utilitzada per fer-los. 2.2 El llenguatge XML 2.2.1 Què és XML? XML són les sigles de Extensible Markup Language (Llenguatge de Marques Extensible), desenvolupat pel World Wide Web Consortium (W3C). XML és un metallenguatge, és a dir, és un llenguatge que permet definir altres llenguatges segons les necessitats de lʼusuari. Els objectius de disseny del XML destaquen la usabilitat, generalitat i simplicitat a través dʼInternet. Encara que el disseny de XML es centra en documents estructurats, és ampliament utilitzats per representació de dades estructurades arbitràries, per exemple en els serveis web. Moltes APIs sʼhan desenvolupat per a que els desenvolupadors de software puguin processar dades dels documents XML i ajudar en la definició de llenguatges basats en XML. 2.2.2 Estructura bàsica Els documents XML formen una estructura dʼarbre que comencen a lʼarrel, que conté altres elements, que a la vegada poden contenir altres elements, etc. Cada element té una etiqueta que lʼidentifica. Aquí podem veure un exemple dʼun document xml. Fig.2.3 Exemple dʼun fitxer XML La primera línia és la declaració del document, anomenada pròleg. Defineix la versió de XML (1.0) i la codificació que sʼutilitza (ISO-8859-1 = conjunt de caràcters Llatí-1/Europa Oest). La resta del document és el cos, que conté la informació. 35 Assistent per desenvolupar videojocs en Flash La primera línia del cos descriu lʼelement arrel del document, que és com dir que el document és dʼaquest tipus. (<nota> = aquest document és una nota). Les següents línies descriuen els elements fills de lʼarrel (destinatari, remitent, assumpte, cos). Finalment lʼúltima línia descriu el final e lʼelement arrel (</nota>). Es pot deduir fàcilment dʼaquest exemple que el document XML conté una nota dʼen Joel destinada a en Lluis. Això mostra com el llenguatge és molt intuïtiu i autodescriptiu. 2.2.3 Avantatges del llenguatge XML Ampliació de lʼaplicació: els documents XML són fàcilment extensibles. A mida que es van necessitant noves dades és molt fàcil afegir-les al llenguatge de lʼaplicació sense gairebé afegir codi, per tant, això fa que la funcionalitat de lʼaplicació sigui fàcilment ampliable. Facilitat de comprensió: el llenguatge XML és molt fàcil i intuïtiu dʼutilitzar com ja sʼha mostrat a lʼexemple anterior. Per tant això facilita la tasca del desenvolupador a lʼhora de dissenyar lʼestructura de dades on es guardarà la informació. Intercanvi de dades: com ja sʼha comentat abans, és molt important per aquest projecte la possibilitat dʼintercanviar dades entre varies aplicacions, ja que necessitarem comunicar lʼassistent o planificador amb el programa que interpretarà aquesta planificació i lʼexecutarà. Amb XML aquesta tasca és molt simple ja que qualsevol aplicació pot llegir i manipular informació dels documents XML. Compatibilitat: XML és un llenguatge universal que es pot utilitzar en qualsevol plataforma i tecnologia. Per tant això fa que lʼaplicació sigui fàcilment transportable a qualsevol plataforma. A més a més, la informació generada pel planificador podria ser aprofitada per una aplicació desenvolupada amb altra tecnologia sense cap tipus de problema de compatibilitat. 36 Assistent per desenvolupar videojocs en Flash 2.3 Lʼentorn de treball En aquest capítol es valora el software utilitzat durant el projecte per desenvolupar lʼaplicació i es comenten els avantatges i desavantatges que sʼhan trobat a lʼhora de treballar amb ell. 2.3.1 Adobe Flash CS5 Flash CS5 és lʼentorn de desenvolupament oficial dʼAdobe per treballar amb la tecnologia Flash i ActionScript. Durant la primera part del projecte es va utilitzar la versió anterior del software (Flash CS4), però al final es va decidir canviar a la nova ja que els canvis necessaris al projecte eren pràcticament nuls i així es disposava dels últims avenços i avantatges de lʼentorn de desenvolupament. Adobe Flash CS5 permet a lʼusuari adaptar lʼentorn de treball segons les seves necessitats ja que depenen de quin sigui el projecte o la feina que sʼestà realitzant sʼutilitzen eines molt diferents. Existeixen perfils predefinits per desenvolupadors dʼaplicacions web, dissenyadors gràfics, per projectes de vídeo o aplicacions interactives. Però fins i tot podem adaptar cadascun dʼaquests perfils a les nostres necessitats particulars i crear perfils nous. Un dels avantatges més importants pels desenvolupadors dʼaplicacions Flash que ofereix Flash CS5 respecte de la versió anterior és la nova manera de treballar amb codi ActionScript que ens ofereix. Abans no hi havia un bon ressaltat de codi, i no hi havia recomanació de codi ni auto completar codi per classes que no fossin de la IDE de Flash. Això ha canviat amb CS5, ara si tenim aquests avantatges que ofereixen la majoria dels IDE coneguts per altres llenguatges de programació. Flash CS5 és un entorn de treball molt fàcil dʼutilitzar i molt personalitzable. Amb les últimes millores a més a més és una bona eina per desenvolupadors dʼaplicacions. També tenim lʼavantatge de poder dissenyar al mateix entorn tota la interfície gràfica de lʼaplicació i afegir codi a qualsevol objecte gràfic. Encara que existeixen altres eines per treballar amb Flash, Flash CS5 és lʼeina més adient per aquest projecte i és la que sʼha utilitzat per dissenyar tots els elements gràfics i per fer tot el codi de lʼaplicació. 37 Assistent per desenvolupar videojocs en Flash 3. Anàlisi de requeriments Aquest capítol de la memòria té com a objectiu extreure tots els requeriments de lʼaplicació que es vol desenvolupar per aconseguir complir tots els objectius marcats a lʼinici del projecte. Per fer això necessitarem primer tots els casos dʼús que ens ajudaran a obtenir tot el llistat de requeriments. Sʼestudiaran dos tipus de requeriments, els requeriments funcionals i els requeriments no funcionals. A continuació es fa una breu descripció de cadascun dʼells: Requeriments funcionals: Especifiquen una funcionalitat que ha de realitzar lʼaplicació o algun component de lʼaplicació. Requeriments no funcionals: No especifiquen que farà lʼaplicació, sinó com ho farà. 3.1 Usuaris del producte Els usuaris del producte representen totes aquelles persones que utilitzaran o poden utilitzar el software que volem desenvolupar. El seu anàlisi és necessari per determinar les funcionalitats del sistema que requeriran aquests usuaris a més de determinar altres requeriments no funcionals com la interfície gràfica, la usabilitat o altres detalls que els desenvolupadors dʼuna aplicació poden no tenir en compte. 3.1.1 Categories Els usuaris es poden distribuir en diferents categories en funció dʼun perfil segons el seu rol, la seva experiència i possibles problemes que poden tenir amb la tecnologia utilitzada. Es poden distingir els següents usuaris que podrien utilitzar lʼaplicació: Jugador: aquest usuari utilitzarà els jocs o aplicacions flash resultants de la utilització de lʼassistent per part dʼun dels altres tipus dʼusuari. La seva única funció és utilitzar el resultat, i no el producte, per tant, no ha de conèixer lʼexistència de lʼassistent i ha de poder utilitzar els jocs sense cap problema. 38 Assistent per desenvolupar videojocs en Flash En aquest cas els seus coneixements de Flash no tenen cap rellevància ja que no utilitzaran en cap moment lʼaplicació. Usuari inexpert amb Flash: aquest és lʼusuari final de lʼaplicació i principal beneficiari del seu desenvolupament. Cal tenir en compte que és probable que no estigui familiaritzat amb aquest tipus dʼaplicacions i que no coneix la tecnologia Flash. Els seus coneixements de la tecnologia poden ser molt limitats per tant cal fer lʼaplicació accessible per a aquest tipus dʼusuari per tal dʼevitar que es senti limitat a lʼhora dʼutilitzar-lo. Dissenyador dʼanimacions Flash: aquest tipus dʼusuari també és un dels objectius de lʼaplicació, encara que pràcticament ja queda cobert amb els requisits que sʼextrauran amb lʼusuari inexpert. Com que és molt probable que aquests usuaris tinguin coneixements medis o avançats de Flash, caldrà incorporar funcionalitats addicionals que els permetin fer jocs una mica més elaborats encara que els usuaris inexperts no puguin aprofitar-les. Desenvolupador dʼaplicacions Flash: els desenvolupadors dʼaplicacions Flash no són part de lʼobjectiu de lʼaplicació ja que sʼentén que ja són capaços de desenvolupar jocs més avançats dels que es podrien fer amb lʼaplicació. Tot i això, podrien utilitzar-la igualment com a planificador de les seves tasques i incorporar transicions més o menys complexes. No es tindran en compte pel desenvolupament de lʼaplicació perquè caldria afegir moltes funcionalitats avançades que afegirien complexitat que no volem pels altres usuaris. 3.1.2 Prioritats Com que lʼaplicació té diversos tipus diferents dʼusuaris amb necessitats diferents i, en ocasions, contradictòries, és necessari establir unes prioritats pels usuaris més importants per al desenvolupament dʼaquesta aplicació. Com ja sʼha pogut llegir en lʼapartat anterior, no tots els usuaris es tindran en compte de la mateixa manera. Sʼha decidit fer una divisió dels usuaris en dos tipus diferents, els usuaris clau i els usuaris secundaris. Els usuaris clau són els màxims participants a la utilització de lʼaplicació i, per tant, seʼls donarà més importància que als altres. 39 Assistent per desenvolupar videojocs en Flash Usuaris clau: aquest usuaris són els usuaris inexperts amb la tecnologia Flash i en part, els dissenyadors, com a subconjunt. Lʼaplicació només té sentit si es utilitzada per ells, ja que són els principals beneficiaris de la seva existència. Serà necessari que aquests usuaris puguin utilitzar fàcilment lʼaplicació per a tenir èxit. Usuaris secundaris: els jugadors són les persones que utilitzaran el resultat final que ofereix lʼassistent però no utilitzaran lʼaplicació directament. Com que el producte no va dirigit a ells i no obtenen cap benefici directament, no es poden considerar usuaris clau, però són necessaris per a que tingui sentit lʼexistència de lʼaplicació. Per tant, sʼhan de tenir en compte. Usuaris no importants: aquests usuaris són els que poden utilitzar lʼaplicació però que no són realment importants per al disseny del producte. En aquest cas són els desenvolupadors, ja que aquests usuaris ja coneixen Flash i disposen de moltes eines per desenvolupar aplicacions. Per tant, podran utilitzar lʼaplicació però hauran dʼacceptar que va dirigida cap a un altre tipus dʼusuari. 3.1.3 Participació La participació dels usuaris a lʼaplicació serà diferent en cada cas, per tant, sʼhan de tenir en compte les necessitats de cadascun dʼells per fer lʼespecificació de requeriments. Si no es tenen en compte els requeriments concrets de cada tipus dʼusuari es podria construir un sistema que no serveix a tots els usuaris implicats. Es determinarà la seva participació i implicació al projecte segons la classificació anterior. Usuari inexpert: són les persones que utilitzaran el producte més habitualment i, per tant, lʼaplicació haurà de ser lo suficientment senzilla i intuïtiva com per a que la puguin utilitzar amb facilitat i sense necessitat de gaire aprenentatge sobre la tecnologia Flash. Dissenyadors: aquests usuaris segurament seran menys habituals que els anterior però també poden ser usuaris del sistema. Com a requeriment addicional aquests usuaris necessitaran dʼalguna funcionalitat de tipus més avançada per dissenyar aplicacions una mica més elaborades. 40 Assistent per desenvolupar videojocs en Flash Jugadors: com a usuaris secundaris de lʼaplicació, no es tindrà en compte la participació dʼaquests usuaris pel disseny de lʼaplicació principal. Però caldrà afegir una funcionalitat final que permeti a aquests usuaris utilitzar els jocs o aplicacions resultants de lʼassistent sense cap problema i sense cap necessitat de tenir coneixements sobre aquest projecte. Desenvolupadors: com a usuaris no importants per al nostre projecte, no es tindran en compte pràcticament en cap aspecte del disseny de lʼaplicació. Només es tindrà en compte que si un usuari avançat utilitza lʼaplicació pugui fer-ho amb eficiència. 3.2 Requeriments funcionals: Casos dʼús A continuació es descriuen les funcionalitats principals que ha de tenir lʼaplicació que es desenvolupa en aquest projecte mitjançant lʼespecificació dels casos dʼús essencials del sistema. Els casos dʼús del producte ajuden a descriure què és el que el sistema ha de fer des del punt de vista de lʼusuari i com interactua amb ell. Cada cas dʼús ha estat redactat seguint una plantilla basada en lʼespecificació de casos dʼús per extreure els requeriments funcionals. Cal destacar, també, que els casos dʼús sʼhan definit de forma abstracta sense tenir en compte la tecnologia utilitzada ni la implementació. 3.2.1 Crear una planificació Descripció: lʼusuari desitja crear una nova planificació dʼun videojoc o aplicació. Importància: és un cas dʼús clau per al desenvolupament de lʼaplicació, ja que si no existeix la possibilitat de crear una planificació nova, la resta de funcionalitats no tenen sentit. Dependències i conflictes: aquest cas dʼús és independent dels altres i no crea cap conflicte amb cap altre cas dʼús. Actors: tots els usuaris que utilitzin lʼaplicació el faran servir. 41 Assistent per desenvolupar videojocs en Flash Precondició: No hi ha cap precondició per aquest cas dʼús. Condició de satisfacció: lʼaplicació ha creat una nova planificació amb el nom que lʼusuari ha indicat. Escenari principal: 1 Lʼusuari indica a lʼaplicació que vol crear una nova planificació. 2 El sistema mostra a lʼusuari el formulari de creació. 3 Lʼusuari introdueix un nom per la nova planificació i accepta. 4 El sistema esborra la pantalla i crea una nova planificació amb el nom indicat. 5 El sistema informa a lʼusuari que sʼha creat la nova planificació de forma correcta. Extensions: 4a El nom introduit per lʼusuari és incorrecte o inexistent. " 4a1 El sistema notifica a lʼusuari que el nom és incorrecte. " " 4a1a Es torna al pas 3. *a Lʼusuari decideix cancel·lar. " *a1 Finalitza el cas dʼús. 3.2.2 Desar una planificació Descripció: lʼusuari desitja desar la planificació que està editant. Importància: és un cas dʼús clau per al desenvolupament de lʼaplicació, ja que si no existeix la possibilitat de desar la planificació, no es podria jugar al joc fora de lʼaplicació ni tampoc de desar i recuperar el treball fet durant una sessió. Dependències i conflictes: Té dependència amb crear planificació, ja que si no existeix la planificació no es pot desar. No crea cap conflicte amb cap altre cas dʼús. Actors: tots els usuaris que utilitzin lʼaplicació el faran servir. Precondició: Sʼha creat una nova planificació. Condició de satisfacció: lʼaplicació ha desat la planificació amb el nom que lʼusuari ha indicat. 42 Assistent per desenvolupar videojocs en Flash Escenari principal: 1 Lʼusuari indica a lʼaplicació que vol desar la planificació actual. 2 El sistema mostra a lʼusuari la finestra per desar fitxers. 3 Lʼusuari escull un directori, introdueix un nom per la planificació i accepta. 4 El sistema crea un nou fitxer que conté la informació de la planificació actual amb el nom indicat i el desa al directori indicat. 5 El sistema informa a lʼusuari que sʼha desat la planificació de forma correcta. Extensions: *a Lʼusuari decideix cancel·lar. " *a1 Finalitza el cas dʼús. 3.2.3 Carregar una planificació Descripció: lʼusuari desitja carregar una planificació dʼun videojoc o aplicació que sʼhavia creat i desat prèviament. Importància: és un cas dʼús clau per al desenvolupament de lʼaplicació, ja que si no existeix la possibilitat de carregar una planificació desada, no es podria continuar la feina al acabar una sessió de treball amb lʼaplicació. Dependències i conflictes: depen de crear planificació nova i desar planificació, ja que no pot existir si no existeixen els altres dos. No hi ha conflictes. Actors: tots els usuaris que utilitzin lʼaplicació el faran servir. Precondició: Existeix una planificació creada i desada prèviament. Condició de satisfacció: lʼaplicació ha carregat una planificació a partir del fitxer que lʼusuari ha indicat. Escenari principal: 1 Lʼusuari indica a lʼaplicació que vol carregar una planificació. 2 El sistema mostra a lʼusuari la finestra per buscar fitxers. 3 Lʼusuari escull el fitxer de la planificació que vol carregar i accepta. 4 El sistema esborra la pantalla i carrega la planificació a partir del fitxer indicat. 5 El sistema informa a lʼusuari que sʼha carregat la planificació de forma correcta. 43 Assistent per desenvolupar videojocs en Flash Extensions: 4a El fitxer escollit per lʼusuari és incorrecte. " " 4a1 El sistema notifica a lʼusuari que el fitxer és incorrecte. " 4a1a Finalitza el cas dʼús. *a Lʼusuari decideix cancel·lar. " *a1 Finalitza el cas dʼús. 3.2.4 Afegir una activitat nova Descripció: lʼusuari desitja afegir una nova activitat a la planificació actual. Importància: és un cas dʼús clau per al desenvolupament de lʼaplicació, ja que si no existeix la possibilitat dʼafegir activitats, no es podrien fer planificacions. Dependències i conflictes: només depen de crear planificació i no afegeix cap conflicte. Actors: tots els usuaris que utilitzin lʼaplicació el faran servir. Precondició: Existeix una planificació activa. Condició de satisfacció: lʼaplicació ha afegit a la planificació actual una nova activitat amb les propietats que lʼusuari ha indicat. Escenari principal: 1 Lʼusuari indica a lʼaplicació que vol afegir una nova activitat. 2 El sistema mostra a lʼusuari el formulari de creació. 3 Lʼusuari introdueix les propietats per la nova activitat i accepta. 4 El sistema crea una nova activitat amb les propietats indicades i lʼafegeix a la planificació actual. 5 El sistema informa a lʼusuari que sʼha afegit la nova activitat de forma correcta. 44 Assistent per desenvolupar videojocs en Flash Extensions: 4a Alguna de les propietats introduïdes per lʼusuari és incorrecte. " 4a1 El sistema notifica a lʼusuari quina de les propietats és incorrecte. " " 4a1a Es torna al pas 3. *a Lʼusuari decideix cancel·lar. " *a1 Finalitza el cas dʼús. 3.2.5 Editar les propietats dʼuna activitat Encara que hi hauran diferents propietats per les activitats i lʼusuari pot voler canviar només una, es pot considerar que tot pertany al mateix cas dʼús ja que en realitat el procés serà sempre el mateix. Només variarà la informació que serà canviada a dins del sistema una vegada sʼacceptin els canvis. Descripció: lʼusuari desitja modificar alguna de les propietats dʼuna activitat existent a la planificació actual. Importància: No és un cas dʼús clau per lʼaplicació, però afegeix qualitat a la usabilitat de lʼaplicació ja que sense la posibilitat de fer modificacions, sʼhaurien dʼesborrar i crear noves activitats contínuament. Dependències i conflictes: depen directament dʼafegir activitat i no afegeix cap conflicte. Actors: tots els usuaris que utilitzin lʼaplicació el faran servir. Precondició: Existeix una planificació activa que conté alguna activitat. Condició de satisfacció: lʼaplicació ha modificat les propietats de lʼactivitat seleccionada amb les noves propietats que lʼusuari ha indicat. Escenari principal: 1 Lʼusuari selecciona una de les activitats de la planificació actual. 2 El sistema mostra a lʼusuari el formulari dʼedició de propietats de lʼactivitat. 3 Lʼusuari introdueix les propietats que vol modificar de lʼactivitat seleccionada i accepta. 4 El sistema modifica totes les propietats editades per lʼusuari. 45 Assistent per desenvolupar videojocs en Flash 5 El sistema informa a lʼusuari que sʼha modificat lʼactivitat de forma correcta. Extensions: 4a Alguna de les propietats introduïdes per lʼusuari és incorrecte. " 4a1 El sistema notifica a lʼusuari quina de les propietats és incorrecte. " " 4a1a Es torna al pas 3. *a Lʼusuari decideix cancel·lar. " *a1 Finalitza el cas dʼús. 3.2.6 Esborrar una activitat Descripció: lʼusuari desitja esborrar alguna de les activitats existents a la planificació actual. Importància: No és un cas dʼús clau per lʼaplicació, però afegeix qualitat a la usabilitat de lʼaplicació ja que sense la posibilitat dʼesborrar activitats, sʼhaurien de crear noves planificacions per fer qualsevol modificació. Dependències i conflictes: depen directament dʼafegir activitat i no afegeix cap conflicte. Actors: tots els usuaris que utilitzin lʼaplicació el faran servir. Precondició: Existeix una planificació activa que conté alguna activitat. Condició de satisfacció: lʼaplicació ha esborrat lʼactivitat seleccionada i totes les transicions de les quals és origen o destí. Escenari principal: 1 Lʼusuari selecciona una de les activitats de la planificació actual. 2 El sistema mostra a lʼusuari el formulari dʼedició de propietats de lʼactivitat. 3 Lʼusuari indica al sistema que vol esborrar lʼactivitat. 4 El sistema esborra totes les transicions de les quals lʼactivitat seleccionada és origen o destí. 5 El sistema esborra lʼactivitat seleccionada de la planificació actual. 6 El sistema informa a lʼusuari que sʼha esborrat lʼactivitat de forma correcta. 46 Assistent per desenvolupar videojocs en Flash Extensions: 6a Lʼactivitat esborrada és lʼactivitat inicial de la planificació. " 6a1 El sistema posa la segona activitat com activitat inicial si existeix. " " " 6a2 El sistema informa a lʼusuari que sʼha esborrat lʼactivitat inicial i lʼindica quina és la nova activitat inicial. " 6a2a Finalitza el cas dʼús. *a Lʼusuari decideix cancel·lar. " *a1 Finalitza el cas dʼús. 3.2.7 Afegir una transició nova Descripció: lʼusuari desitja afegir una nova transició a la planificació actual. Importància: és un cas dʼús clau per al desenvolupament de lʼaplicació, ja que si no existeix la possibilitat dʼafegir transicions, no es podrien fer planificacions ja que no hi hauria ordre dʼexecució entre les diferents activitats. Dependències i conflictes: depen de crear planificació i afegir activitat, ja que no pot existir una transició sense activitats. No afegeix cap conflicte. Actors: tots els usuaris que utilitzin lʼaplicació el faran servir. Precondició: Existeix una planificació activa i, com a mínim, una activitat. Condició de satisfacció: lʼaplicació ha afegit a la planificació actual una nova transició amb les propietats que lʼusuari ha indicat. Escenari principal: 1 Lʼusuari selecciona un punt dʼorigen dʼuna de les activitats existents a la planificació actual. 2 El sistema mostra a lʼusuari el formulari de propietats de la transició. 3 Lʼusuari selecciona el punt destí de la transició, introdueix les seves propietats i accepta. 4 El sistema crea una nova transició que té com a origen i destí els punts seleccionats per lʼusuari i també té les propietats indicades. 5 El sistema informa a lʼusuari que sʼha afegit la nova transició de forma correcta. 47 Assistent per desenvolupar videojocs en Flash Extensions: 4a Alguna de les propietats introduïdes per lʼusuari és incorrecte. " 4a1 El sistema notifica a lʼusuari quina de les propietats és incorrecte. " " 4a1a Es torna al pas 3. *a Lʼusuari decideix cancel·lar. " *a1 Finalitza el cas dʼús. 3.2.8 Editar les propietats dʼuna transició Encara que hi poden haver diferents propietats per les transicions i lʼusuari pot voler canviar només una, igual que sʼha fet amb les activitats, es pot considerar que tot pertany al mateix cas dʼús ja que en realitat el procés serà sempre el mateix. Descripció: lʼusuari desitja modificar alguna de les propietats dʼuna transició existent a la planificació actual. Importància: No és un cas dʼús clau per lʼaplicació, però afegeix qualitat a la usabilitat de lʼaplicació ja que sense la posibilitat de fer modificacions, sʼhaurien dʼesborrar i crear noves transicions contínuament. Dependències i conflictes: depen directament dʼafegir transició i no afegeix cap conflicte. Actors: tots els usuaris que utilitzin lʼaplicació el faran servir. Precondició: Existeix una planificació activa que conté alguna transició. Condició de satisfacció: lʼaplicació ha modificat les propietats de la transició seleccionada amb les noves propietats que lʼusuari ha indicat. Escenari principal: 1 Lʼusuari selecciona una de les transicions de la planificació actual. 2 El sistema mostra a lʼusuari el formulari dʼedició de propietats de la transició. 3 Lʼusuari introdueix les propietats que vol modificar de la transició seleccionada i accepta. 4 El sistema modifica totes les propietats editades per lʼusuari. 48 Assistent per desenvolupar videojocs en Flash 5 El sistema informa a lʼusuari que sʼha modificat la transició de forma correcta. Extensions: 4a Alguna de les propietats introduïdes per lʼusuari és incorrecte. " 4a1 El sistema notifica a lʼusuari quina de les propietats és incorrecte. " " 4a1a Es torna al pas 3. *a Lʼusuari decideix cancel·lar. " *a1 Finalitza el cas dʼús. 3.2.9 Esborrar una transició Descripció: lʼusuari desitja esborrar alguna de les transicions existents a la planificació actual. Importància: No és un cas dʼús clau per lʼaplicació, però afegeix qualitat a la usabilitat de lʼaplicació ja que sense la posibilitat dʼesborrar transicions, sʼhaurien de crear noves planificacions per fer qualsevol modificació. Dependències i conflictes: depen directament dʼafegir transició i no afegeix cap conflicte. Actors: tots els usuaris que utilitzin lʼaplicació el faran servir. Precondició: Existeix una planificació activa que conté alguna transició. Condició de satisfacció: lʼaplicació ha esborrat la transició seleccionada. Escenari principal: 1 Lʼusuari selecciona una de les transicions de la planificació actual. 2 El sistema mostra a lʼusuari el formulari dʼedició de propietats de la transició. 3 Lʼusuari indica al sistema que vol esborrar la transició. 4 El sistema esborra la transició seleccionada de la planificació actual. 5 El sistema informa a lʼusuari que sʼha esborrat la transició de forma correcta. Extensions: *a Lʼusuari decideix cancel·lar. " *a1 Finalitza el cas dʼús. 49 Assistent per desenvolupar videojocs en Flash 3.2.10 Afegir condicions a una transició Descripció: lʼusuari desitja trencar la sequència de reproducció per defecte de la planificació afegint una condició a una transició. La sequència es trenca perquè en cas que no es compleixi aquesta condició no sʼexecutarà la part de la planificació que penji dʼaquesta transició. Importància: És un cas dʼús totalment opcional per aquesta aplicació. Sʼinclou perquè afegeix funcionalitat avançada pels usuaris més avançats que vulguin afegir complexitat a les seves planificacions. Dependències i conflictes: depen directament dʼafegir transició i no afegeix cap conflicte. Actors: Només serà utilitzat pels usuaris més avançats com els dissenyadors dʼanimacions o els desenvolupadors, ja que requereix coneixement de la tecnologia Flash. Precondició: Existeix una planificació activa que conté alguna transició. Condició de satisfacció: lʼaplicació ha modificat el tipus de la transició seleccionada a condicional amb les propietats que lʼusuari ha indicat. Escenari principal: 1 Lʼusuari selecciona una de les transicions de la planificació actual. 2 El sistema mostra a lʼusuari el formulari dʼedició de propietats de la transició. 3 Lʼusuari introdueix la condició per lʼexecució de la transició seleccionada i accepta. 4 El sistema introdueix la condició indicada per lʼusuari a la transició. 5 El sistema informa a lʼusuari que sʼha modificat la transició de forma correcta. Extensions: 4a La condició introduïda per lʼusuari és incorrecte. " 4a1 El sistema notifica a lʼusuari que la condició es incorrecte. " " 4a1a Es torna al pas 3. *a Lʼusuari decideix cancel·lar. " *a1 Finalitza el cas dʼús. 50 Assistent per desenvolupar videojocs en Flash 3.2.11 Previsualitzar la reproducció del joc Descripció: lʼusuari desitja previsualitzar lʼexecució de la planificació actual. Importància: No és un cas dʼús clau per lʼaplicació, però afegeix qualitat a la usabilitat de lʼaplicació ja que sense la posibilitat de fer previsualitzacions, sʼhauria de desar la planificació i executar-la cada vegada. Dependències i conflictes: depen dʼafegir planificació, ja que en realitat no es necessita cap activitat ni transició per intentar fer una previsualització, però per poder previsualitzar alguna cosa sí és necessari que existeixi com a mínim una activitat. No afegeix cap conflicte. Actors: tots els usuaris que utilitzin lʼaplicació el faran servir. Precondició: Existeix una planificació activa. Condició de satisfacció: lʼaplicació ha executat la planificació activa en lʼordre correcte i respectant totes les transicions establertes per lʼusuari. Escenari principal: 1 Lʼusuari indica a lʼaplicació que vol començar la previsualització. 2 El sistema comproba que existeixi una activitat inicial i comença lʼexecució. 3 El sistema executa les activitats de manera sequencial, respectant les transicions i les condicions en cas que hi hagi alguna. 4 El sistema informa a lʼusuari que sʼha executat la previsualització de forma correcta. Extensions: 3a No existeix cap activitat a la planifiació. " 4a1 El sistema notifica a lʼusuari que no hi ha res per previsualitzar. " " 4a1a Finalitza el cas dʼús. 51 Assistent per desenvolupar videojocs en Flash 3.2.12 Aturar una previsualització Descripció: lʼusuari desitja aturar la previsualització que sʼestà executant. Importància: No és un cas dʼús clau per lʼaplicació, però afegeix qualitat a la usabilitat de lʼaplicació ja que sense la posibilitat dʼaturar previsualitzacions, lʼusuari hauria dʼesperar sempre a que la previsualització acabi, i en alguns casos, mai acabaria perquè poden existir bucles a la planificació. Dependències i conflictes: depen directament de previsualitzar, ja que si no sʼestà executant una previsualització, no tindrem res per aturar. No afegeix cap conflicte. Actors: tots els usuaris que utilitzin lʼaplicació el faran servir. Precondició: Hi ha una previsualització executant-se. Condició de satisfacció: lʼaplicació ha aturat la previsualització que sʼestava executant i ha tornat al mode dʼedició de la planificació. Escenari principal: 1 Lʼusuari indica a lʼaplicació que vol aturar la previsualització. 2 El sistema atura lʼexecució de la previsualització. 3 El sistema informa a lʼusuari que sʼha aturat la previsualització de forma correcta. Extensions: Sense extensions 3.2.13 Començar partida Descripció: lʼusuari desitja executar una planificació, desada prèviament, fora de lʼeditor. Importància: És un cas dʼús clau per lʼaplicació, ja que lʼobjectiu és que es pugui utilitzar la planificació creada amb lʼeditor, i si no es pot executar el joc no tindrien sentit la resta de funcionalitats. 52 Assistent per desenvolupar videojocs en Flash Dependències i conflictes: depen dʼafegir planificació, ja que en realitat no es necessita cap activitat ni transició per intentar fer una execució, però per poder executar alguna cosa sí és necessari que existeixi com a mínim una activitat. També depen de desar planificació, ja que lʼexecució es produeix fora de lʼeditor i es necessita accedir a la informació dʼalguna manera. No afegeix cap conflicte. Actors: qualsevol usuari el podria fer servir, però principalment seran els jugadors els que utilitzin aquest cas dʼús. Precondició: Existeix una planificació desada prèviament. Condició de satisfacció: lʼaplicació ha executat la planificació desada en lʼordre correcte i respectant totes les transicions establertes. Escenari principal: 1 Lʼusuari executa lʼaplicació de joc. 2 El sistema carrega la planificació desada. 3 El sistema comproba que existeixi una activitat inicial i comença lʼexecució. 4 El sistema executa les activitats de manera sequencial, respectant les transicions i les condicions en cas que hi hagi alguna. 5 El sistema informa a lʼusuari que lʼexecució ha finalitzat correctament. Extensions: 3a No existeix cap activitat a la planifiació. " 4a1 El sistema notifica a lʼusuari que no hi ha res per executar. " " 4a1a Finalitza el cas dʼús. *a Lʼusuari decideix cancel·lar. " *a1 Finalitza el cas dʼús. 53 Assistent per desenvolupar videojocs en Flash 3.3 Requeriments no funcionals En aquest apartat es descriuen els requeriments no funcionals de lʼaplicació, és a dir, tots aquells objectius que lʼaplicació hauria dʼassolir independentment de les funcionalitats que tingui i de la tecnologia que utilitza. 3.3.1 Requeriments dʼaspecte (look & feel) En aquesta primera secció es concreten els requeriments que determinen els aspectes visuals o dʼestil que haura de seguir lʼaplicació. 3.3.1.1 Apariència atractiva Descripció: lʼaplicació ha de tenir una apariència atractiva per lʼusuari. Justificació: atraure als usuaris per a que sʼanimin a utilitzar lʼaplicació. Condició de satisfacció: la valoració mitjana sobre lʼapariència de lʼaplicació dʼuna mostra representativa dʼusuaris és bona o molt bona. Importància: donat que els usuaris principals de lʼaplicació són usuaris inexperts amb la tecnologia és important que estiguin còmodes utilitzant lʼaplicació. 3.3.1.2 Homogeneitat Descripció: lʼaplicació hauria de presentar un disseny uniforme en tots els seus menus. Justificació: fer que el sistema sigui més intuïtiu i millorar la seva comprensió. Condició de satisfacció: tots els menus presenten el mateix aspecte i estan situats al mateix lloc de la finestra de lʼaplicació. Importància: és bastant important ja que necessitem que lʼaplicació tingui una usabilitat molt senzilla pels usuaris inexperts. 54 Assistent per desenvolupar videojocs en Flash 3.3.2 Requeriments dʼusabilitat La usabilitat es refereix a la capacitat que té un software de ser comprès, après i usat en unes condicions determinades. En aquest apartat es concreten els requeriments que permetran que lʼaplicació tingui un grau dʼusabilitat acceptable pels usuaris que tindran contacte directe amb el sistema. 3.3.2.1 Facilitat dʼús Descripció: els usuaris hauran de trobar-se amb una aplicació fàcil dʼutilitzar. Justificació: els usuaris prefereixen utilitzar aplicacions senzilles amb les quals no perdin gaire temps. Condició de satisfacció: els usuaris podran realitzar qualsevol acció del sistema sense haver de navegar per més de 3 menus diferents. Importància: és clau que lʼaplicació sigui fàcil dʼutilitzar ja que els usuaris principals no tenen coneixements importants sobre la tecnologia. 3.3.2.2 Navegació amb ratolí Descripció: sʼha de poder navegar per tota lʼaplicació utilitzant només el ratolí. Justificació: els usuaris inexperts prefereixen utilitzar el ratolí per realitzar les accions. Condició de satisfacció: els usuaris podran navegar per tots els menus del sistema utilitzant només el ratolí. Importància: no és un requeriment clau ja que els usuaris sʼadaptarien a utilitzar el teclat igualment, però com afegeix usabilitat pels usuaris inexperts sʼha de tenir en compte. 55 Assistent per desenvolupar videojocs en Flash 3.3.2.3 Control dʼerrors Descripció: el sistema ajudarà a lʼusuari a no cometre errors a lʼhora dʼintroduir dades. Justificació: fer que el sistema sigui més senzill dʼutilitzar. Condició de satisfacció: lʼaplicació no permet introduir dades que sap que són incorrectes o que no tenen el format correcte. Importància: no és un requeriment gaire important però farà que sʼagiliti la utilització de lʼaplicació. 3.3.2.4 Sistema intuitiu Descripció: la utilització de lʼaplicació ha de ser totalment intuïtiva. Justificació: és important que els usuaris aprenguin a utilitzar el sistema de forma bàsica sense necessitat dʼuna formació específica. Condició de satisfacció: qualsevol usuari pot aprendre a utilitzar lʼaplicació sense formació prèvia. Importància: és un requeriment clau per a que els usuaris inexperts siguin capaços dʼutilitzar lʼaplicació sense necessitat de seguir instruccions o tutorials que els farien perdre el temps. 3.3.2.4 Nom de la planificació Descripció: si sa carregat una planificació o sʼha creat una de nova, el seu nom ha dʼapareixer a la pantalla en tot moment. Justificació: mantenir a lʼusuari informat del que està fent. Condició de satisfacció: lʼusuari pot veure el nom de la planificació que està editant en tot moment. Importància: no és un requeriment important, però afegeix cert grau dʼusabilitat. 56 Assistent per desenvolupar videojocs en Flash 3.3.3 Requeriments de rendiment En aquesta secció sʼacota els requeriments dʼescalabilitat del sistema ja que el temps de resposta no serà un problema. 3.3.3.1 Escalabilitat Descripció: lʼarquitectura de lʼaplicacio ha de ser escalable. Justificació: en cas de necessitat, les funcionalitats de lʼaplicació sʼhan de poder modificar o ampliar afectant lo mínim possible al codi ja escrit. Condició de satisfacció: lʼaplicació permet incloure el desenvolupament de noves funcionalitats i requeriments, així com la modificació o eliminació de funcionalitats existents dʼuna forma poc problemàtica. Importància: no és un requeriment important per lʼèxit de lʼaplicació o per assolir els objectius del projecte, però és essencial pel futur desenvolupament que pugui tenir lʼaplicació. 3.3.4 Requeriments operacionals i de lʼentorn Aquesta secció fa referència als requeriments que tenen a veure amb lʼentorn físic en el qual serà utilitzada lʼaplicació i amb la integració amb altres aplicacions que són necessàries per a que el sistema funcioni de manera satisfactòria. 3.3.4.1 Navegadors Descripció: lʼaplicació ha de poder-se utilitzar als navegadors més utilitzats. Justificació: és necessari que els jocs es puguin transportar a diferents sistemes. Condició de satisfacció: lʼaplicació es visualitza i funciona correctament a tots els navegadors. Importància: no és un requeriment clau, però és necessari que el treball fet al planificador es pugui utilitzar a diferents sistemes per a que tingui una utilitat real. 57 Assistent per desenvolupar videojocs en Flash 3.3.5 Requeriments de suport i manteniment Aquest apartat especifica el nivell de suport a lʼusuari que és necessari per aquest projecte i de quina manera es donarà aquest suport a lʼaplicació. 3.3.5.1 Suport a lʼusuari Descripció: lʼaplicació ha dʼoferir algun tipus de tutorial. Justificació: els usuaris han de poder resoldre els seus dubtes sobre la utilització del sistema. Condició de satisfacció: lʼaplicació conté tutorials que ofereixen informació sobre els aspectes bàsics del funcionament del sistema. Importància: no és un requeriment important, però ja que els nostres usuaris principals són inexperts amb la tecnologia, és una manera més de reforçar que podran utilitzar lʼaplicació sense gaires problemes. 3.3.6 Requeriments de seguretat Aquests requeriments sʼencarreguen de determinar aspectes relatius a la integritat i la privacitat de les dades i les restriccions dʼaccés al sistema. 3.3.6.1 Integritat de les dades Descripció: lʼaplicació ha dʼasegurar la integritat de les dades que els usuaris introdueixen al sistema. Justificació: lʼaplicació ha de ser robusta per evitar errors i pèrdua de dades ja que els usuaris no volen perdre el seu treball. Condició de satisfacció: lʼaplicació no té cap inconsistència a les dades en qualsevol instant de temps. Importància: no és un requeriment clau per assolir els objectius, però sí és important per a que la satisfacció dels usuaris amb lʼaplicació sigui alta. 58 Assistent per desenvolupar videojocs en Flash 3.4 Qualitat dels requeriments Tots els requeriments han estat revisats i corregits seguint un control de qualitat. Per considerar que un requeriment és de qualitat ha de seguir els següents punts: Completesa: tots els requisits han de ser complets i tenir totes les dades necessàries. A més, hem de saber perquè hi són i analitzar si la seva existència té sentit. Consistència: a més de ser complets, hem de saber que volen dir exactament i que tothom entengui el mateix de cada requeriment. Sʼha dʼaconseguir tenir requeriments que no siguin ambigus. Rellevància i viabilitat: el sistema pot tenir moltes opcions que es poden afegir i que podrien ser interessants però sʼha de considerar si aporten alguna cosa important. És possible que els usuaris principals de lʼaplicació no el necessitin i que suposi una despesa de temps o recursos important. Els requeriments han de ser valuosos pels usuaris principals de lʼaplicació i òbviament han de ser viables, ja que no té sentit tenir requeriments que no es poden dur a terme. Justificació: finalment hem de veure que efectivament els requeriments estan lligats a les solucions dels problemes i necessitats que plantejen els objectius dʼaquest projecte. Sʼha intentat que tots els requeriments estiguin descrits i justificats de la millor manera possible sense que resulti complex entendreʼls. 59 Assistent per desenvolupar videojocs en Flash 4. Especificació En aquesta secció es volen especificar més formalment les funcionalitats que tindrà lʼaplicació final a partir dels requeriments que sʼhan estudiat prèviament. Per fer-ho es faran servir dos models diferents que expliquen diferents aspectes del sistema: el model de casos dʼús i el model conceptual. Per fer els models sʼutilitzarà el llenguatge de modelatge UML (Unified Modeling Language) que és lʼestàndard per lʼespecificació i disseny de software. 4.1 Model de Casos dʼÚs El Model de Casos dʼÚs descriu les funcionalitats de lʼaplicació que es vol dissenyar partint de les funcionalitats requerides a lʼanàlisi de requeriments i tenint en compte la importància de cadascun dels requeriments. Un cas dʼús representa una unitat discreta dʼinteracció entre un usuari (humà o màquina) i el sistema. Aquesta interacció és una sola unitat significativa com pot ser crear una activitat o esborrar-la. Cada cas dʼús descriu una funcionalitat que es construirà a lʼaplicació i, al mateix temps, pot incloure la funcionalitat dʼun altre cas dʼús, requerir-la pel seu funcionament o ampliar un altre cas dʼús amb el seu comportament. 4.1.1 Actors del sistema Els casos dʼús estan generalment relacionats amb “actors”, que són entitats humanes o de la màquina que utilitzen o interactuen amb el sistema per realitzar un treball significatiu que ajudi a assolir una meta. El conjunt de casos dʼús als quals un actor té accés defineix el seu rol global al sistema i lʼabast de les seves accions. En llenguatge UML un actor es representa mitjançant el dibuix dʼun ninot i el seu nom associat. Fig.4.1 dibuix dʼun actor en UML. 60 Assistent per desenvolupar videojocs en Flash En aquest projecte es distingeix entre dos tipus dʼactors: Jugador: són aquells usuaris que només utilitzen lʼaplicació per jugar a jocs o utilitzar aplicacions creades anteriorment amb lʼaplicació principal, és a dir, lʼassistent per desenvolupar jocs Flash o planificador dʼactivitats. Dissenyador: aquests usuaris, a més de poder jugar, són els que utilitzen lʼaplicació principal per planificar i dissenyar els jocs resultants. 4.1.2 Diagrama de casos dʼús Amb el diagrama de casos dʼús es vol donar una visió global del sistema. Es mostraran les funcionalitats que es volen implementar, i es relacionaran amb els actors que hi participen. Fig.4.2 Diagrama de casos dʼús. 61 Assistent per desenvolupar videojocs en Flash 4.1.3 Especificació de casos dʼús Aquesta secció té com a objectiu fer la descripció dels casos dʼús més en detall per conèixer de forma clara i desambigua com és el comportament del sistema davant la interacció que es produeix amb els actors. Per evitar ambigüitats a lʼespecificació, cada descripció de cas dʼús contindrà els següents punts: Descripció: comentaris generals que descriuen el comportament del cas dʼús. Actor principal: actor que inicia el cas dʼús i participa durant el curs dʼesdeveniments. Pre-condició: casos dʼús que sʼhan dʼexecutar obligatòriament abans de que es pugui executar aquest. Post-condició: condicions que sʼhan de complir al acabar el cas dʼús. Escenari principal: descripció del flux dʼesdeveniments que hi ha durant el cas dʼús. Els esdeveniments poden ser accions de lʼusuari o del sistema. Escenaris alternatius: descripció de fluxos alternatius en cas que es produeixi algun error o lʼusuari cancel·li lʼexecució del cas dʼús. 4.1.3.1 Crear Planificació Descripció: lʼusuari crearà una nova planificació buida que tindrà el nom indicat. Actor Principal: Dissenyador. Pre-Condició: Post-Condició: existeix una nova planificació buida amb el nom indicat per lʼusuari. Escenari principal i alternatius: corresponen als del requeriment funcional “crear una planificació”. 62 Assistent per desenvolupar videojocs en Flash 4.1.3.2 Desar Planificació Descripció: lʼusuari desarà la planificació que està editant en aquell moment. Actor Principal: Dissenyador. Pre-Condició: Crear Planificació. Post-Condició: existeix un fitxer a la ubicació indicada i amb el nom indicat per lʼusuari que conté la informació de la planificació. Escenari principal i alternatius: corresponen als del requeriment funcional “desar una planificació”. 4.1.3.3 Carregar Planificació Descripció: lʼusuari carregarà una planificació a partir dʼun fitxer desat prèviament. Actor Principal: Dissenyador. Pre-Condició: Desar Planificació. Post-Condició: existeix una planificació carregada a lʼaplicació que conté tota la informació que hi havia al fitxer seleccionat. Escenari principal i alternatius: corresponen als del requeriment funcional “carregar una planificació”. 4.1.3.4 Afegir Activitat Descripció: lʼusuari crearà una nova activitat indicant al sistema el nom, el nombre de transicions, el fitxer flash corresponent de lʼactivitat, el color amb el que es mostrarà a lʼesquema de la planificació i si lʼactivitat finalitzarà de forma condicional o no. Totes les propietats tenen valors per defecte i no són obligatòries per crear lʼactivitat. 63 Assistent per desenvolupar videojocs en Flash Actor Principal: Dissenyador. Pre-Condició: Crear Planificació o Carregar Planificació. Post-Condició: existeix una nova activitat a la planificació que sʼestà editant que conté totes les propietats indicades per lʼusuari. Escenari principal i alternatius: corresponen als del requeriment funcional “afegir una activitat nova”. 4.1.3.5 Editar Activitat Descripció: lʼusuari seleccionarà una activitat existent i editarà les seves propietats. Es podrà editar qualsevol de les propietats esmentades a lʼapartat anterior a més de la seva posició a lʼàrea dʼedició. Actor Principal: Dissenyador. Pre-Condició: Afegir Activitat. Post-Condició: lʼactivitat seleccionada sʼha modificat dʼacord amb les noves propietats indicades per lʼusuari. Escenari principal i alternatius: corresponen als del requeriment funcional “editar les propietats dʼuna activitat”. 4.1.3.6 Esborrar Activitat Descripció: lʼusuari esborrarà una activitat existent de la planificació. Actor Principal: Dissenyador. Pre-Condició: Afegir Activitat. Post-Condició: lʼactivitat seleccionada ja no existeix a la planificació ni tampoc qualsevol transició que la tingués com origen o destí. 64 Assistent per desenvolupar videojocs en Flash Escenari principal i alternatius: corresponen als del requeriment funcional “esborrar una activitat”. 4.1.3.7 Afegir Transició Descripció: lʼusuari crearà una nova transició indicant al sistema lʼactivitat origen, lʼactivitat destí, el color amb el que es mostrarà a lʼesquema de la planificació i si lʼactivitat origen és condicional, la condició que sʼha de complir per que sʼutilitzi la transició. Totes les propietats tenen valors per defecte i no són obligatòries per crear la transició excepte lʼactivitat origen i lʼactivitat destí. Actor Principal: Dissenyador. Pre-Condició: Afegir Activitat. Post-Condició: existeix una nova transició a la planificació que sʼestà editant que conté totes les propietats indicades per lʼusuari. Escenari principal i alternatius: corresponen als del requeriment funcional “afegir una transició nova”. 4.1.3.8 Editar Transició Descripció: lʼusuari seleccionarà una transició existent i editarà les seves propietats. Es podrà editar qualsevol de les propietats esmentades a lʼapartat anterior excepte les activitats origen i destí. Actor Principal: Dissenyador. Pre-Condició: Afegir Transició. Post-Condició: la transició seleccionada sʼha modificat dʼacord amb les noves propietats indicades per lʼusuari. Escenari principal i alternatius: corresponen als del requeriment funcional “editar les propietats dʼuna transició”. 65 Assistent per desenvolupar videojocs en Flash 4.1.3.9 Esborrar Transició Descripció: lʼusuari esborrarà una transició existent de la planificació. Actor Principal: Dissenyador. Pre-Condició: Afegir Transició. Post-Condició: la transició seleccionada ja no existeix a la planificació. Escenari principal i alternatius: corresponen als del requeriment funcional “esborrar una transició”. 4.1.3.10 Previsualitzar Descripció: lʼusuari previsualitzarà lʼexecució de la planificació que està editant sense sortir de lʼaplicació dʼedició. Les activitats sʼexecutaran seqüencialment en lʼordre establert per les transicions afegides per lʼusuari, sempre respectant les possibles transicions condicionals, que només sʼexecutaran si es compleix la condició indicada. Actor Principal: Dissenyador. Pre-Condició: Afegir Planificació. Post-Condició: la planificació sʼha executat seqüencialment en lʼordre correcte. Escenari principal i alternatius: corresponen als del requeriment funcional “previsualitzar la reproducció del joc”. 4.1.3.11 Aturar Visualització Descripció: lʼusuari aturarà una previsualització abans de que acabi i tornarà al mateix estat dʼedició que hi havia abans de la previsualització. Actor Principal: Dissenyador. Pre-Condició: Previsualitzar. 66 Assistent per desenvolupar videojocs en Flash Post-Condició: la previsualització sʼha aturat i lʼaplicació ha tornat a lʼestat previ. Escenari principal i alternatius: corresponen als del requeriment funcional “aturar una previsualització”. 4.1.3.12 Jugar Descripció: lʼusuari executarà el mode de joc de lʼaplicació y sʼexecutarà una planificació desada prèviament per un dissenyador. Sʼexecutarà aquella planificació que el dissenyador hagi decidit que sʼexecuti en el mode de joc. Actor Principal: Jugador. Pre-Condició: Desar Planificació. Post-Condició: la planificació establerta com a planificació de joc sʼha executat seqüencialment en lʼordre correcte. Escenari principal i alternatius: corresponen als del requeriment funcional “començar partida”. 4.2 Model Conceptual El model conceptual del sistema és una visió estàtica dels objectes i les classes que componen lʼanàlisi de lʼespai de lʼaplicació. En aquesta secció es farà un diagrama de classes en UML que sʼutilitza per especificar el patró dels objectes que es produeixen en temps dʼexecució. Una classe és una especificació dʼun objecte del sistema i un objecte és una instància concreta dʼaquesta classe. Les classes poden heretar dʼaltres classes, és a dir, hereten tot el comportament i lʼestat dels seus pares i poden afegir noves funcionalitats pròpies. Una classe encapsula lʼestat (els atributs) i ofereix serveis per poder-la manipular (el comportament). 67 Assistent per desenvolupar videojocs en Flash 4.2.1 Diagrama de classes Fig.4.3 Diagrama de classes. 68 Assistent per desenvolupar videojocs en Flash 4.2.2 Descripció de les classes i els seus atributs A continuació es farà una breu descripció de cadascuna de les classes del diagrama de classes on sʼexplicara el que representa cada classe i els atributs que conté. A més a més també sʼestudia la població de cadascun dʼaquests tipus dʼentitat. La població dʼuna entitat és el conjunt dʼinstàncies que existeixen dʼaquesta entitat al domini en un punt temporal determinat. Generalment, la població dʼuna entitat varia en el temps al llarg del període de vida del sistema (població no restringida). No obstant, existeixen casos particulars: els tipus dʼentitat constants i permanents. Un tipus dʼentitat és constant si la seva població sempre és la mateixa en qualsevol moment (mai canvia) i és permanent si les seves instàncies sempre existeixen (la seva població no pot baixar mai). 4.2.2.1 Assistent Descripció: representa lʼassistent, que sʼencarrega de gestionar les planificacions i interactuar amb lʼusuari. Atributs: no conté atributs ja que no necessita guardar informació addicional. Població: permanent. Només existeix una instància dʼassistent i mai pot deixar dʼexistir. 4.2.2.2 Planificació Descripció: conté tota la informació dʼuna planificació i gestiona les seves activitats. Atributs: Només conté el nom de la planificació. Població: es pot considerar constant si només es treballa amb una planificació i crear-la directament al començament sense necessitat dʼinteracció amb lʼusuari. En cas que es treballi amb més dʼuna planificació al mateix temps seria de població no restringida. 69 Assistent per desenvolupar videojocs en Flash 4.2.2.3 Activitat Descripció: representa una tasca a realitzar de la planificació, és a dir, una activitat que sʼhaurà dʼexecutar al joc o al reproductor de planificacions. També gestiona totes les transicions que tenen com a origen lʼactivitat. Atributs: " Nom: el nom de lʼactivitat. " Color: el color que tindrà lʼactivitat gràficament a lʼesquema visual. " " " " Nombre de transicions: el nombre màxim de transicions que tindrà lʼactivitat. Fitxer Flash: el fitxer de flash associat a lʼactivitat que sʼhaurà dʼexecutar. Condicional: indica si lʼactivitat permet lʼús de condicions a les seves transicions. Població: No restringida. Es poden crear i eliminar instàncies dʼactivitat en qualsevol moment. 4.2.2.4 Transició Descripció: representa una transició entre dues activitats de la planificació. Atributs: " Color: el color que tindrà la transició gràficament a lʼesquema visual. " Condició: indica la condició que sʼha de complir per a que es pugui utilitzar " aquesta transició. Només es tindrà en compte si lʼactivitat origen és " condicional. Població: No restringida. Es poden crear i eliminar instàncies de transició en qualsevol moment. 4.2.2.5 Reproductor Descripció: representa el reproductor de planificacions que sʼencarregarà de fer les previsualitzacions. Atributs: no conté atributs ja que no necessita guardar informació. 70 Assistent per desenvolupar videojocs en Flash Població: permanent. Només existeix una instància de reproductor i no pot deixar dʼexistir mai. 4.2.2.6 Joc Descripció: representa el joc que utilitzarà les planificacions fetes, independentment de lʼassistent, per executar-les. Atributs: no conté atributs ja que no necessita guardar informació. Població: permanent. Només existeix una instància de joc i no pot deixar dʼexistir mai. 4.2.3 Descripció de les associacions En aquesta secció es farà una breu descripció de cadascuna de les associacions del diagrama de classes. Sʼexplicarà què representa cadascuna de les associacions i sʼindicaran quines són les classes associades i la multiplicitat. En aquest cas també sʼestudiarà la població de cada associació. En lʼapartat anterior sʼha definit el concepte de població dʼun tipus dʼentitat i sʼhan explicat els casos particulars de constants i permanents. Aquestes particularitats també es poden aplicar a les associacions. Per tant, la població dʼuna associació és el conjunt de les seves instàncies que existeixen al domini en un punt temporal determinat. 4.2.3.1 Assistent-Planificació Descripció: lʼassistent o planificador edita una planificació que després utilitzarà per altres funcions. Aquesta associació representa la planificació que sʼestà editant a lʼassistent. Multiplicitat dʼAssistent: 1 (una planificació només es pot editar amb lʼassistent) Multiplicitat de Planificació: 0..1 (es pot estar editant una planificació o cap) Població: al igual que amb la classe planificació es pot considerar constant si només es treballa amb una planificació que sigui constant. En cas que es treballi amb més dʼuna planificació al mateix temps seria de població no restringida. 71 Assistent per desenvolupar videojocs en Flash 4.2.3.2 Planificació-Activitat Descripció: una planificació conté diferents activitats que sʼexecutaran al joc. Aquesta associació representa cadascuna de les activitats que estan incloses a una planificació. Multiplicitat de Planificació: 1 (una activitat només pot pertànyer a una planificació) Multiplicitat dʼActivitat: * (una planificació pot tenir qualsevol nombre dʼactivitats) Població: no restringida. Una planificació pot afegir i esborrar activitats en qualsevol moment. 4.2.3.3 Origen - Destí (Activitat-Activitat) Descripció: una activitat conté un cert nombre de transicions cap a altres activitats de la planificació. Aquesta associació representa cadascuna dʼaquestes transicions. Multiplicitat dʼOrigen: * (una activitat destí pot tenir qualsevol nombre dʼactivitats origen relacionades amb ella). Multiplicitat de Destí: * (una activitat origen pot tenir qualsevol nombre dʼactivitats destí relacionades amb ella). Encara que això no és completament cert ja que en realitat el nombre màxim seria lʼatribut Nombre de Transicions de lʼactivitat. Població: constant des del punt de vista de lʼactivitat. Una activitat tindrà en tot moment un nombre constant de transicions que comencen en ella, que és exactament el nombre de transicions que indica lʼatribut. Aquestes transicions no tenen destí i per tant no apareixen a lʼesquema visual de lʼaplicació. Des del punt de vista de lʼaplicació la població és no restringida, perquè sʼafegeixen i esborren activitats en tot moment, i, per tant, també transicions. 72 Assistent per desenvolupar videojocs en Flash 4.2.3.4 Assistent-Reproductor Descripció: lʼassistent utilitza un reproductor de planificacions que el permetrà fer les previsualitzacions. Aquesta associació representa el reproductor que lʼassistent utilitza. Multiplicitat dʼAssistent: 1 (lʼassistent només utilitza un reproductor) Multiplicitat de Reproductor: 1 (el reproductor només sʼutilitza a lʼúnic assistent que existeix). Població: permanent. Només existeix una instància dʼaquesta associació i no pot deixar dʼexistir. 4.2.3.5 Joc-Planificació Descripció: el joc reprodueix una planificació creada amb lʼassistent. Aquesta associació representa la planificació que es reprodueix. Multiplicitat de Joc: 0..1 (una planificació pot ser reproduïda pel joc o no) Multiplicitat de Planificació: 1 (el joc només pot reproduir una planificació en un moment de temps). Població: constant, perquè en tot moment només existeix una instància dʼaquesta associació, encara que no és permanent perquè pot variar la planificació que es reprodueix. 73 Assistent per desenvolupar videojocs en Flash 5. Disseny A lʼetapa dʼespecificació sʼhan establert totes les funcionalitats necessàries per aconseguir assolir els objectius del projecte tenint en compte els requeriments dels usuaris que sʼhan trobat a lʼetapa dʼanàlisi. Ara és el moment de definir com es faran totes aquestes funcionalitats, quines tecnologies sʼutilitzaran i, en definitiva, com estarà dissenyada lʼaplicació per aconseguir oferir les funcionalitats indicades. 5.1 Decisions de disseny En aquesta secció sʼexplicaran totes les decisions de disseny que sʼhan pres i que es tindran en compte per fer la implementació de lʼaplicació. Per implementar lʼaplicació sʼutilitzarà ActionScript 3, el llenguatge de programació de Flash que ja sʼha explicat a la secció de tecnologies. Les vistes de lʼaplicació es faran amb les eines de dibuix que ofereix Flash i les dades es guardaran en fitxers XML. Per fer la implementació de lʼaplicació sʼutilitzarà el patró arquitectònic ModelVista-Controlador (MVC), que defineix lʼestructura bàsica del sistema. El patró arquitectònic MVC aïlla la lògica de lʼaplicació (model conceptual) de la interfície dʼusuari (presentació i interacció amb lʼusuari). Això permet desenvolupar de forma independent cadascuna de les parts de lʼaplicació. Fig.5.2 Model-Vista-Controlador 74 Assistent per desenvolupar videojocs en Flash El model defineix el comportament de lʼaplicació i la interacció amb les dades, respon a les sol·licituds dʼinformació sobre el seu estat (normalment des de la vista) i respon a les instruccions per canviar aquest estat (normalment des de el controlador). En els sistemes basats en esdeveniments, el model notifica als observadors quan canvia perquè puguin reaccionar als canvis. Les vistes transformen el model en una presentació gràfica amb una forma adequada per la interacció amb lʼusuari. Hi pot haver diferents vistes dʼun mateix model per a diferents propòsits. El controlador o controladors reben els esdeveniments de lʼentrada i inicien la resposta del sistema demanant als objectes del model les accions necessàries. Un controlador accepta lʼentrada de lʼusuari i envia instruccions a les vistes i el model per realitzar accions basades en aquesta entrada. Encara que hi ha diferents variacions del patró MVC, totes segueixen un flux dʼexecució bàsic, que és el següent: Lʼusuari interactua amb la interfície dʼusuari dʼalguna manera. (per exemple, prem un botó del ratolí). El controlador captura lʼesdeveniment dʼentrada de la interfície dʼusuari i converteix lʼesdeveniment en una acció de dʼusuari que sigui comprensible pel model. El controlador notifica al model de lʼacció de lʼusuari, la qual cosa podria produir un canvi dʼestat del model si lʼacció és de modificació. El controlador notifica a la vista que sʼha executat lʼacció i la vista actualitza el seu estat obtenint les dades necessàries del model. La interfície dʼusuari espera noves interaccions de lʼusuari, reiniciant dʼaquesta manera el cicle. 75 Assistent per desenvolupar videojocs en Flash 5.2 El Model El model del sistema conté totes les classes necessàries per representar una planificació dʼuna partida dʼun joc o dʼun conjunt dʼactivitats si es considera de forma més general. També conté les classes necessàries per gestionar i reproduir aquestes planificacions. Per dissenyar un bon model sʼutilitzaran alguns patrons de disseny comuns al desenvolupament de software que ajuden a tenir un codi més organitzat, més eficient i millor encapsulat. En la següent secció sʼexpliquen amb una mica més de detall. 5.2.1 Patrons de disseny Sovint moltes persones han observat que existeixen bones solucions per a certs problemes comuns que apareixen repetidament als bons disseny de software. A través dels anys els dissenyadors aprenen bones maneres de resoldre certs tipus de problemes, i la millor solució tendeix a ser usada novament. En lloc de crear un nou disseny des de el principi en cada oportunitat, els dissenyadors experts sʼestalvien treball utilitzant aquestes solucions “comuns” usades en els seus dissenys previs. Aquestes solucions estàndards poden no ser òptimes en tots els aspectes, però són molt bones i són dissenys útils que han estat comprovats per anys dʼexperiència. Aquestes solucions comuns sʼanomenen patrons de disseny. Els patrons de disseny ajuden a resoldre problemes comuns al desenvolupament de software oferint solucions genèriques que cadascú pot adaptar a les necessitats del seu projecte. Els patrons de disseny han dʼexplicar perquè una situació particular és un problema i perquè es considera que la solució proposada és una bona solució. En aquest projecte sʼutilitzen principalment quatre patrons de disseny molt comuns i també molt útils ja que ajuden a tenir una bona estructura a la implementació de lʼaplicació. Els patrons que sʼutilitzen són el patró expert, el patró creador, el patró observador i el patró controlador que sʼexpliquen amb una mica més de detall als següents apartats. 76 Assistent per desenvolupar videojocs en Flash 5.2.1.1 Patró Expert El que es planteja en aquest patró és assignar la responsabilitat sobre una acció que cal realitzar a lʼexpert en la informació que cal per realitzar-la, és a dir, la classe que té la informació necessària per complir amb la responsabilitat. El problema que resol el patró expert està referit al principi més bàsic mitjançant el qual les responsabilitats són assignades en el disseny orientat a objectes. El model conceptual del sistema pot definir moltes classes diferents, i una aplicació pot definir centenars o milers de responsabilitats a ser complertes. Durant el disseny orientat a objectes, quan les interaccions entre objectes són definides, sʼescolleixen les assignacions de les responsabilitats a les classes. Fent aquestes assignacions bé, els sistemes tendeixen a ser fàcils dʼentendre, mantenir i estendre. 5.2.1.2 Patró Creador Aquest patró serveix per assignar responsabilitats de creació dʼobjectes als objectes que més interactuen amb ells. Per ser més específic, el patró assigna a la classe B la responsabilitat de crear una instància de la classe A si alguna de les següents premisses és certa: • • • • B afegeix objectes dʼA B conté objectes dʼA B registra instàncies dʼobjectes dʼA B utilitza molts objectes dʼA • B és el creador dels objectes dʼA Si hi ha més dʼuna opció, les primeres condicions són més importants que les últimes, per tant serà millor creador una classe que afegeix la classe A que una classe que utilitza molts objectes dʼA. La creació dʼobjectes és una de les activitats més comunes en els sistemes orientats a objectes, per tant, és molt útil tenir un sistema per assignar la responsabilitat de crear cada objecte. Si sʼassignen de manera correcta, sʼincrementa la claredat del codi, la encapsulació i la reutilització. 77 Assistent per desenvolupar videojocs en Flash 5.2.1.3 Patró Observador El patró observador defineix una dependència del tipus un a molts entre objectes, de manera que quan un dels objectes canvia el seu estat, lʼobservador sʼencarrega de notificar el canvi a tots els altres dependents. Fig.5.1 Patró observador. Els observadors han dʼimplementar uns mètodes mitjançant els quals el Subjecte és capaç de notificar als seus observadors subscrits els canvis que sʼhan fet perquè tots ells tingui lʼoportunitat dʼactualitzar el seu propi estat. En aquest projecte, com que utilitzem ActionScript amb Flash, aquest patró ja ve implementat directament al control dʼesdeveniments que ens facilita lʼAPI de Flash i que sʼha explicat al capítol de tecnologies. 5.2.1.4 Patró Controlador El patró controlador planteja que hi hagi una classe que sʼencarrega de establir un sistema de missatges entre la interfície dʼusuari i la resta del sistema i, per tant, que gestiona tot el flux dʼesdeveniments al sistema. El controlador principal pot delegar les responsabilitats també a patrons més específics. En el cas dʼaquest projecte cadascun dels elements de la interfície dʼusuari contarà amb el seu propi controlador que gestionarà tot el flux dʼesdeveniments. Concretament es contarà amb un menú dinàmic que canviarà el seu estat segons el que estigui fent lʼusuari i un àrea dʼinteracció on es dibuixarà lʼesquema de la planificació de forma interactiva. 78 Assistent per desenvolupar videojocs en Flash 5.2.2 Diagrama de classes de disseny Fig.5.3 Diagrama de classes de disseny. 79 Assistent per desenvolupar videojocs en Flash 5.2.3 Model de dades Aquesta secció descriu lʼestructura de les dades que es guarden a la base de dades del sistema, encara que en aquest cas, no és realment una base de dades sinó fitxers XML que guardaran lʼestructura de les planificacions per poder-les carregar i desar a disc. A la imatge següent es pot veure lʼestructura bàsica dʼun fitxer XML que guarda lʼestructura dʼuna planificació del projecte. Fig.5.4 Esquema dels fitxers XML. 80 Assistent per desenvolupar videojocs en Flash 5.3 Els Controladors Els controladors de lʼaplicació controlen tot el flux dʼesdeveniments entre les vistes i el model i gestionen tots els esdeveniments dʼentrada que provoca lʼusuari quan interacciona amb els elements de la interfície dʼusuari. A més a més també gestionen els errors que es poden produir i comuniquen a lʼusuari a través de les vistes dʼaquests errors. A lʼaplicació dʼaquest projectes hi haurà un controlador principal, anomenat controlador de lʼassistent que sʼencarrega dʼinicialitzar els controladors de lʼàrea interactiva i del menú dinàmic. El joc té un controlador propi ja que la seva execució és independent de lʼassistent i, per tant, necessita gestionar les seves pròpies operacions independentment. A la secció anterior ja sʼhan pogut veure tots els controladors amb els seus atributs i operacions al diagrama de classes de disseny. Els controladors formen part de les classes del sistema i interaccionen amb les classes que formen part del model conceptual. A continuació es mostraran les vistes de lʼaplicació i es podrà veure amb més detall el que realment gestionen aquests controladors i els possibles esdeveniments que es poden produir a lʼaplicació. 5.4 Les Vistes Les vistes de lʼaplicació sʼencarreguen de mostrar a lʼusuari totes les opcions disponibles a lʼassistent, a més a més de mostrar gràficament lʼestructura de la planificació i permetre modificar-la dinàmicament amb controls interactius del ratolí. En aquesta aplicació hi ha una vista principal que mostra tota la informació en una finestra, però dividirem lʼexplicació en dues parts que estan clarament diferenciades degut al seu comportament. Les primeres són les vistes del menú dinàmic, que està situat a lʼesquerra de la finestra i canvia la seva aparença mostrant diferents opcions segons les accions de lʼusuari. Finalment mirarem les possibilitats que ens ofereix lʼàrea interactiva on es pot veure gràficament lʼestructura de la planificació i fer diferents accions amb els elements gràfics. 81 Assistent per desenvolupar videojocs en Flash 5.4.1 El menú dinàmic El menú dinàmic de lʼaplicació té una aparença inicial que mostra les opcions que es poden dur a terme en qualsevol moment de lʼedició de la planificació que són les següents. Fig.5.5 Vista del menú inicial. Com es pot veure a la imatge, totes les opcions disponibles a lʼinici són totes aquelles operacions que no necessiten de cap pre-condició per funcionar correctament. En realitat la primera hauria de ser crear planificació, però com que al final sʼha decidit que només es treballarà amb una planificació, al inicialitzar el controlador de lʼassistent, ja es crea automàticament aquesta planificació buida inicial. Això permet que es puguin afegir activitats des de lʼinici. 5.4.1.1 Afegir activitat Quan es selecciona lʼopció dʼafegir activitat a la planificació, el menú dinàmic canvia i ofereix noves opcions que permeten introduir les dades inicials que es volen posar a lʼactivitat que es vol crear. Una vegada sʼaccepta la creació, lʼactivitat sʼafegeix a lʼàrea interactiva automàticament per poder interactuar amb ella. Com es pot veure a la imatge següent, tots els camps per crear lʼactivitat ja tenen un valor per defecte i, per tant, no cal introduir cap dada per afegir la nova activitat, i més endavant podrem modificar-la si volem. 82 Assistent per desenvolupar videojocs en Flash Fig.5.6 Vista del menú afegir activitat. 5.4.1.2 Editar activitat Fig.5.7 Vista del menú editar activitat. 83 Assistent per desenvolupar videojocs en Flash A la dreta de la vista es pot veure una porció de lʼàrea interactiva on es veuen els elements gràfics de la planificació, en aquest cas veiem una representació gràfica dʼuna activitat, i, a lʼesquerra, el menú dinàmic a canviat perquè lʼactivitat està seleccionada i mostra les opcions necessàries per modificar lʼactivitat seleccionada o esborrar-la. 5.4.1.3 Editar transició Fig.5.8 Vista del menú editar transició. Aquí es poden veure dos activitats i una transició de lʼactivitat 1 cap a lʼactivitat 4. Com que la transició ha estat seleccionada a lʼàrea interactiva, novament el menú dinàmic canvia les seves opcions per adaptar-se a la situació i mostra les opcions necessàries per editar la transició o esborrar-la. No existeix una vista per afegir transicions ja que sʼha decidit deixar aquesta funcionalitat completament per lʼàrea interactiva i serà en aquell apartat on sʼexplicarà com funciona exactament. 84 Assistent per desenvolupar videojocs en Flash 5.4.1.4 Desar i carregar una planificació Fig.5.9 Vista de la finestra per carregar fitxers XML. Fig.5.10 Vista de la finestra per desar fitxers XML. 85 Assistent per desenvolupar videojocs en Flash En aquestes imatges es poden veure les finestres que surten quan sʼindica a lʼaplicació que es vol desar o carregar una planificació. Aquestes vistes són independents del sistema ja que venen donades pel sistema operatiu on sʼexecuta lʼaplicació i la funcionalitat ja està implementada per lʼAPI de Flash. Per tant, en aquest cas, per fer que carregar i desar un fitxer sigui tan intuïtiu com en qualsevol altre aplicació es deixa que siguin les típiques finestres del sistema operatiu les que surtin quan lʼusuari vol realitzar alguna dʼaquestes accions. 5.4.1.5 Previsualitzar Fig.5.11 Vista del menú en previsualització. Quan lʼusuari està previsualitzant una planificació, lʼúnic canvi que es pot veure al menú inicial és que sʼafegeix un botó per aturar la visualització, ja que és lʼúnica funcionalitat que depèn de què sʼestigui previsualitzant. 5.4.2 Lʼàrea interactiva Lʼàrea interactiva de lʼaplicació és simplement un àrea de “dibuix” on sortiran tots els elements que sʼafegeixin a la planificació dʼuna manera gràfica, dʼaquesta manera es podran seleccionar per canviar les seves propietats, moure la seva posició en pantalla o afegir transicions arrossegant el ratolí dʼun punt a un altre. 86 Assistent per desenvolupar videojocs en Flash Fig.5.12 Vista de lʼàrea interactiva. Per seleccionar un element de la planificació, només serà necessari fer click amb el ratolí a sobre de lʼelement. Lʼactivitat o transició que es seleccionin es ressaltaran per que lʼusuari tingui consciència de que sʼha seleccionat lʼelement. A més a més com ja sʼha explicat abans, el menú dinàmic canvia dʼacord amb aquestes interaccions. Només es podran moure interactivament les activitats de la planificació, ja que la posició de les transicions depèn de la posició de les activitats que uneixen. Per tant la posició de les transicions sʼactualitzarà automàticament si es mou alguna de les activitats. Per afegir una transició caldrà seleccionar un punt dʼorigen i després arrossegar el ratolí fins al punt de destí vàlid. Mentre sʼestà realitzant aquesta acció, es mostrarà una línia similar a les transicions ja existents, dibuixada entre el punt dʼorigen i el ratolí, per indicar a lʼusuari que està realitzant lʼacció correctament. Si el punt escollit es correcte sʼafegira el destí seleccionat a la transició. Només seran punts de destí vàlids els punts que representen els punts dʼorigen de les transicions de cada activitat. 87 Assistent per desenvolupar videojocs en Flash 5.5 Realitzacions dels casos dʼús En aquest capítol es vol descriure com es realitzen els casos dʼús al model de disseny, tenint en compte els patrons aplicats i lʼarquitectura que sʼestà utilitzant. Sʼha de tenir en compte que no es descriuran els casos dʼús dʼuna manera exaustiva, només es vol donar una idea general de com serà el funcionament de les funcionalitats principals del sistema. Això ajuda a saber amb més detall com funcionaran els casos dʼús a lʼaplicació final, i així sabrem quines classes necessitarem i quines funcionalitats seran importants a cadascuna dʼaquestes classes. Per fer les realitzacions dels casos dʼús sʼutilitzaran diagrames de seqüència en UML. Cada diagrama de seqüència mostra dʼuna manera intuïtiva quines són les classes que interaccionen al cas dʼús i quines funcions sʼutilitzen per realitzar-lo. Normalment es mostren els actors que interaccionen amb el sistema als diagrames de seqüència però en aquest cas no sʼhan especificat perquè només tenim un actor principal, lʼusuari de lʼaplicació, per tant, sempre que sʼindica una interacció exterior de lʼusuari, és aquest actor el que participa. El jugador no es tindrà en compte en aquest apartat ja que només participa al cas dʼús de jugar, que és un cas dʼús secundari i no es posarà en detall. A continuació es mostraran els diagrames de seqüència dels casos dʼús més importants de lʼaplicació. Cal tenir en compte alguns aspectes significatius a lʼhora dʼentendre el que fan alguns casos dʼús que han canviat des de lʼespecificació, que són els següents: Crear planificació: en realitat no crearem cap planificació, ja que al inicialitzar lʼaplicació es crea la planifiació que sʼutilitzarà durant tota lʼexecució, per tant, el que es fa aquí és esborrar la planificació i deixar-la buida per tornar a començar. Afegir transició: aquest cas dʼús ja no depèn de lʼusuari ja que al crear les activitats, es creen automàticament el nombre de transicions que sʼha indicat al formulari de creació. 88 Assistent per desenvolupar videojocs en Flash Afegir destí, editar transició i esborrar transició: aquestes funcionalitats es transformen en una de sola, ja que com les activitats contenen sempre el nombre de transicions indicat per lʼusuari, afegir un nou destí i editar una transició serà una funcionalitat similar. En el cas dʼesborrar transició es redueix a treure lʼactivitat destí i deixar-la com estava incialment, per tant, també és una edició. 5.5.1 Crear planificació Fig.5.13 Diagrama de seqüència de crear planificació. 5.5.2 Desar planificació Fig.5.14 Diagrama de seqüència de desar planificació. 89 Assistent per desenvolupar videojocs en Flash 5.5.3 Carregar planificació Fig.5.15 Diagrama de seqüència de carregar planificació. 5.5.4 Afegir activitat Fig.5.16 Diagrama de seqüència dʼafegir activitat. 90 Assistent per desenvolupar videojocs en Flash 5.5.5 Editar activitat Fig.5.17 Diagrama de seqüència dʼeditar activitat. 5.5.6 Esborrar activitat Fig.5.18 Diagrama de seqüència dʼesborrar activitat. 91 Assistent per desenvolupar videojocs en Flash 5.5.7 Editar transició Fig.5.19 Diagrama de seqüència dʼeditar transició. 5.5.8 Previsualitzar Fig.5.20 Diagrama de seqüència de previsualitzar. 92 Assistent per desenvolupar videojocs en Flash 5.5.9 Aturar visualització Fig.5.21 Diagrama de seqüència dʼaturar visualització. 93 Assistent per desenvolupar videojocs en Flash 6. Implementació En aquest capítol de la documentació es farà una explicació en detall de les classes que sʼhan implementat per desenvolupar el projecte, que seguiran el disseny que sʼha comentat en lʼapartat anterior amb algunes modificacions que es comentaran en cada cas. LʼActionScript 3 està preparat per treballar directament amb gràfics i animacions de Flash, ja que és el llenguatge de programació creat per manipular els dissenys fets amb Flash. Aquest aspecte repercuteix alhora dʼestructurar la implementació de lʼaplicació ja que les classes que implementarem seran totes subclasses de display objects, ja que totes són objectes que apareixen a lʼescena, és a dir, a la finestra de lʼaplicació. A partir del disseny que sʼha estudiat i dʼaquest últim aspecte que sʼha de tenir en compte han sortit les següents classes. 6.1 El mode edició: lʼassistent Per estructurar lʼaplicació es faran servir dos tipus de mode dʼexecució, que corresponen als dos tipus dʼusuaris diferentes que ens podem trobar, és a dir, els dissenyadors dels jocs o animacions i els jugadors que utilitzaran el resultat de lʼaplicació dʼalguna manera. Cadascun dʼaquests dos modes correspon a una aplicació diferent i, per tant, com a resultat tindrem dues animacions de Flash que es podran executar independenment una de lʼaltra. Això ens permetrà aconseguir que els dissenyadors puguin treballar en les planificacions sense necessitat dʼutilitzar lʼaplicació dels jugadors i que els jugadors puguin utilitzar les animacions o jocs resultants sense tenir consciència de lʼexistència de lʼeditor. Per comunicar lʼapliació dʼedició i lʼaplicació del jugador, sʼutilitzaran fitxers XML que contindran tota la informació necessària per poder reproduir el joc a partir dʼuna planificació feta a lʼassistent. En aquest subapartat es comentaran les classes que sʼhan utilitzat per implementar lʼaplicació principal, és a dir, lʼassistent per crear videojocs. 94 Assistent per desenvolupar videojocs en Flash 6.1.1 La classe flashAssistant La classe flashAssistant correspon al controlador principal de lʼaplicació, sʼencarrega dʼinicialitzar tots els elements gràfics i de gestionar els esdeveniments bàsics de ratolí que sʼutilitzen a la interacció amb lʼusuari. Aquesta classe conté tota la informació de lʼaplicació i la distribueix segons els esdeveniments que es produeixen a les altres classes que actuen com a controladors. Els esdeveniments es controlen amb observadors que ja venen implementats per lʼAPI de Flash. Al inicialitzar la classe sʼactiven els observadors que es necessiten, com, per exemple, el click del ratolí. Per crear una aplicació amb Flash, sʼha de crear un fitxer FLA que contindrà tots els elements gràfics de lʼaplicació. Aquest fitxer ha de tenir assignada una classe principal que defineix el seu comportament. En aquest projecte aquesta és la classe principal de lʼaplicació, per tant, a més de fer de controlador principal, també conté el bucle principal de lʼaplicació. El bucle principal sʼexecuta a cada frame de lʼanimació, ja que en Flash, encara que estem parlant dʼuna aplicació, tot es considera una animació. Aquest bucle sʼencarrega de comprovar lʼestat de lʼaplicació i de realitzar les accions necessàries segons calgui quan lʼestat canvii degut a les interaccions amb lʼusuari. A més a més aquest bucle també actualitza lʼestat de tots els elements gràfics de lʼaplicació per a que lʼusuari tingui en tot moment el feedback necessari. 6.1.1.1 Atributs importants Background: com totes les classes que sʼimplementen en aquest projecte de Flash, hi ha un element gràfic a lʼaplicació que es correspon amb la classe. En aquest cas, aquest element seria la finestra de lʼaplicació que sʼha anomenat “background”, ja que és un fons buit que després sʼomple amb la resta dʼelements. La propietat més important del fons de lʼaplicació és clarament el color, que en aquest cas és fixe ja que no sʼha implementat el canvi de color de la finestra. Local Connection: aquest atribut no apareix ni sʼhavia tingut en compte al disseny ja que és un aspecte purament dependent de la tecnologia Flash. Alhora de fer la reproducció dels fitxers SWF i aconseguir informació sobre el 95 Assistent per desenvolupar videojocs en Flash seu estat per poder fer les transicions condicionals és necessari fer una conexió de comunicació entre lʼaplicació principal i lʼanimació que sʼestà executant, que permet passar paràmetres entre les dues animacions. Aquest atribut conté aquest element que sʼutilitzarà només quan les transicions siguin condicionals. MouseDown, MouseX i MouseY: aquests són atributs dʼestat. Ens indiquen en qualsevol moment de lʼexecució si el ratolí esta clickat i la seva posició a pantalla. Això ens permet determinar si sʼestà clickant algún element concret de lʼentorn gràfic, cap a on esten movent el ratolí mentre realitzem una acció interactiva o quan deixem de clickar-lo. Atributs dʼestat de lʼaplicació: hi ha diversos atributs dʼaquest tipus que ens indiquen en tot moment que sʼestà realitzant a lʼaplicació. Així es manté un control del que es pot fer i el que no es pot fer a cada moment de lʼexecució. Per exemple, no volem que lʼusuari pugui seleccionar una activitat mentre esta movent una altra per la pantalla. Tampoc volem que lʼusuari pugui esborrar la planificació mentre sʼestà realitzant una previsualització. 6.1.1.2 Funcions importants initialize(event): aquesta funció sʼauto executa quan es carrega lʼaplicació, que és precisament lʼesdeveniment que lʼactiva. Sʼencarrega dʼafegir els elements gràfics de lʼaplicació, dʼinicialitzar els atributs i els altres controladors, dʼactivar els observadors dʼesdeveniments que són necessaris i finalment dʼiniciar lʼexecució del bucle principal de lʼaplicació. loadXML(event): quan finalitza la càrrega dʼun fitxer XML al cas dʼús de carregar un fitxer de planificació es crida automàticament a aquesta funció, que sʼencarrega dʼinterpretar totes les dades que conté el fitxer i derivar al controlador de lʼàrea interactiva la creació de les activitats i transicions necessàries per completar la reconstrucció de la planificació contenida al fitxer. feedback(String): aquesta senzilla funció sʼha implementat per donar a lʼusuari un feedback directe sobre les accions que realitza a lʼaplicació. La funció simplement mostra a la pantalla principal un missatge. El missatge 96 Assistent per desenvolupar videojocs en Flash varia i sʼutilitza en tots els punts claus de cada cas dʼús per indicar quan ha finalitzat correctament o quan sʼha produit un error. playGame() i stopGame(): aquest serà el controlador que interaccioni directament amb el reproductor, i aquestes funcions sʼencarreguen dʼiniciar i aturar la previsualització. En el primer cas prepara lʼaplicació per fer-ho i deriva la funcionalitat al reproductor. En el segon simplement atura la reproducció i torna a lʼestat previ a la reproducció. 6.1.2 La classe dynamicMenu La classe dynamicMenu correspon al controlador del menú dinàmic de lʼaplicació, sʼencarrega dʼinicialitzar tots els components gràfics del menú, la seva posició dins de la finestra de lʼaplicació el seu color. Durant lʼexecució de lʼaplicació gestiona tots els esdeveniments que es produeixen al menú dinàmic i adapta el seu contingut segons lʼestat en el que es troba lʼaplicació. La classe conté la informació necessària per controlar lʼestat del menú en qualsevol moment de lʼexecució i conté un bucle principal que es crida des de el controlador principal de lʼaplicació. El bucle principal del menú dinàmic canvia lʼestat del menú segons lʼestat en el que es troba lʼaplicació, és a dir, si lʼusuari ha seleccionat una activitat, llavors es mostraran les opcions dʼedició dʼactivitats, i així amb totes les funcionalitats que el menú proporciona. A més a més del canvi dʼestat, també gestiona els esdeveniments que es produeixen quan lʼusuari selecciona alguna opció del menú i deriva les operacions necessàries cap els altres controladors. 6.1.2.1 Atributs importants Atributs dʼestat del menú: hi ha diverses variables a aquesta classe que serveixen per saber en qualsevol moment de lʼexecució quin és lʼestat del menú dinàmic, és a dir, quin és el menú actiu i quina operació sʼestà realitzant en aquell moment. Això és necessari per actuar en conseqüència quan hi hagi un esdeveniment. Per exemple, el menú dʼedició dʼactivitats sʼutilitza per crear-les i per editar-les, i volem saber quin cas dʼús és el que està realitzant lʼusuari per executar les operacions adients quan es premi el botó dʼacceptar. 97 Assistent per desenvolupar videojocs en Flash Width, Height i color: aquests atributs només indiquen lʼaspecte gràfic que tindrà el menú dinàmic i sʼinicialitzen al crear-lo. Per aquest projecte les dimensions i el color no variaran durant lʼexecució perquè no sʼhan afegit funcionalitats per personalitzar la interfície gràfica. Vistes dels menús: com en totes les classes hi ha un element gràfic que es correspon amb la classe. En aquest cas en realitat és més dʼun element ja que el menú dinàmic conté diferents menús que va mostrant o tancant segons lʼestat de lʼaplicació. Per tant, tenim un submenú per a cadascuna de les vistes que es van mostrar al disseny. 6.1.2.2 Funcions importants initialize(): sʼexecuta quan es crea el menú dinàmic. Sʼencarrega dʼafegir els elements gràfics del menú i dʼinicialitzar els seus atributs. També activa alguns observadors dʼesdeveniments que són necessaris per al bon funcionament dʼalguna de les funcionalitats que ofereix el menú dinàmic. initMenuActivity(...) i initMenuLink(...): aquestes dues funcions són claus per al bon funcionament del menú dinàmic ja que inicialitzen els menús dʼedició dʼactivitats i transicions amb tots els atributs que calen, sempre que es selecciona un element a lʼàrea interactiva o es vol canviar el contigut del menú per algun motiu sʼutilitza una dʼaquestes funcions per actualitzar la informació del menú. refreshMenu(): lʼúltima funció que es comenta dʼaquesta classe només serveix per actualitzar la informació del menú segons lʼestat en el que es troba lʼaplicació en aquell moment. Aquesta funció és senzilla però també necessària per a que sʼactualitzi el menú sempre que es faci alguna operació a lʼàrea interactiva que canvii lʼestat de la planificació. 6.1.3 La classe Board Aquesta classe rep el nom de “Board” per analogia amb els jocs de taula, i correspon al controlador de lʼàrea interactiva. Sʼencarrega dʼinicialitzar lʼaspecte gràfic de lʼàrea interactiva, de gestionar els esdeveniments que es produeixen per la interacció amb lʼusuari amb els elements gràfics de la planificació i de gestionar totes les operacions que impliquin fer canvis a la planificació que sʼestà editant, ja 98 Assistent per desenvolupar videojocs en Flash que com es va comentar en anteriors capítols, sʼha decidit utilitzar una única planificació que sʼesborrarà i modificarà segons calgui. La classe conté la informació necessària per saber quin objecte està seleccionat i sʼestà manipulant en aquell moment a lʼàrea interactiva per poder-lo modificar segons els esdeveniments que es produeixin. En aquesta classe controlador també hi ha un bucle principal que es crida des del controlador principal de lʼaplicació. Aquest bucle serveix per identificar en qualsevol moment de lʼexecució quin objecte està seleccionat, i canviar la selecció segons calgui quan es produeixin esdeveniments dʼinteracció de lʼusuari. A més a més també sʼencarrega dʼefectuar les operacions de moviment dʼobjectes i altres funcionalitats interactives com afegir una transició. 6.1.3.1 Atributs importants Width, Height i color: només indiquen lʼaspecte gràfic que tindrà lʼàrea interactiva i sʼinicialitzen al crear-la. Per aquest projecte les dimensions i el color no variaran durant lʼexecució perquè no sʼhan afegit funcionalitats per personalitzar la interfície gràfica. selected_element: conté en qualsevol moment de lʼexecució lʼelement que hi ha seleccionat a lʼàrea interactiva. Això ens permet accedir directament a lʼelement seleccionat en qualsevol moment i modificar-lo segons les operacions que lʼusuari hagi sol·licitat. planificació: el controlador de lʼàrea interactiva conté la planificació de lʼaplicació, ja que és un objecte únic que modificarem segons lʼestat de lʼaplicació, però sempre serà la mateixa ja que no es treballarà amb diverses planificacions al mateix temps. Vista de lʼàrea interactiva: com la resta de classes de lʼaplicació, aquesta també correspon a un element gràfic de Flash. En aquest cas és lʼàrea interactiva de lʼaplicació que sʼha pogut veure a la secció de vistes del disseny. 99 Assistent per desenvolupar videojocs en Flash 6.1.3.2 Funcions importants initialize(): sʼexecuta al crear lʼàrea interactiva de lʼaplicació i bàsicament sʼencarrega dʼinicialitzar els elements gràfics necessaris per la correcta visualització dʼaquest element. A més a més també inicialitza la planificació buida que es farà servir a lʼinici. addActivity(...), removeActivity(): serveixen per afegir o esborrar activitats de la planificació, són necessàries per manipular lʼestat de la planificació segons les accions de lʼusuari al menú dinàmic i també per reconstruir una planificació guardada a un arxiu XML. exportXML(): amb aquesta funció es vol donar suport a la funcionalitat de desar planificacions en XML. Inicialitza un XML nou amb les dades de format correctes i deriva la funció a les activitats per aconseguir un XML que conté tota la informació de la planificació. clear(): aquesta funcionalitat senzilla correspon al cas dʼús de crear una nova planificació, que simplement esborra el contingut de la planificació i actualitza lʼàrea interactiva que torna al seu estat inicial. 6.1.4 La classe Activity La classe Activity correspon exactament a la classe activitat del model conceptual especificat i també del model de disseny. A més a més també conté lʼelement gràfic de Flash necessari per representar una activitat per pantalla i poder interaccionar amb ella. Principalment gestiona el comportament de les activitats i controla tota la informació que contenen. Aquesta és la primera classe que no té un bucle principal, ja que no correspon a cap controlador de lʼaplicació, només és un element del model. Per tant, conté més funcions per crear, esborrar i modificar aspectes de la classe des de fora que les anteriors. 6.1.4.1 Atributs importants Id: correspon a un identificador numèric únic que tindrà cada activitat a dins dʼuna planificació. Per tant, no poden haver dues activitats amb el mateix 100 Assistent per desenvolupar videojocs en Flash identificador a una planificació, això ens permet identificar cada activitat inequívocament amb aquest atribut i, dʼaquesta manera, poder-les relacionar amb les transicions amb més facilitat. mc: conté el MovieClip de Flash que té el disseny gràfic de lʼactivitat. Com totes les classes a la implementació dʼaquesta aplicació, tenim un element gràfic que es correspon amb ella. Name, color i nLinks: aquests són els atributs que pot editar lʼusuari i que es reflectiran de forma gràfica a lʼesquema visual de la planificació. El nom serà un identificador per lʼusuari de cada activitat, però no sʼutilitza com a identificador intern, així lʼusuari té llibertat per posar el nom que vulgui a cada activitat. El color només varia lʼaspecte gràfic de lʼactivitat i lʼatribut nLinks indica el nombre de punts dʼorigen que tindra lʼactivitat gràficament. En definitiva, aquest nombre de punts també serà el màxim de transicions que puguin començar a una activitat, ja que només es poden afegir punts destí de forma interactiva. El nombre de transicions que poden acabar a una activitat, però, és il·limitat. file: lʼatribut file correspon al nom del fitxer SWF que sʼexecutarà quan es visualitzi aquesta activitat al reproductor de planificacions o al joc. Per editar-lo es farà servir una finestra de càrrega de fitxers i només es podran escollir fitxers SWF. secuential: és només un booleà que indica si lʼactivitat tindrà un comportament sequencial a la visualització. Si aquest atribut és fals, llavors vol dir que les transicions contenen condicions i sʼhan de comprovar. 6.1.4.2 Funcions importants refreshMc(): serveix per actualitzar els elements gràfics dʼuna activitat després de fer qualsevol canvi als seus atributs. addLink(), removeLink(): serveixen per afegir o esborrar transicions de lʼactivitat, són necessàries per manipular lʼestat de lʼactivitat segons les accions de lʼusuari al menú dinàmic i també per reconstruir una planificació guardada a un arxiu XML. 101 Assistent per desenvolupar videojocs en Flash select(), unselect(), dragging(): actualitzen lʼestat gràfic de lʼactivitat, ja que lʼaspecte gràfic dʼuna activitat canvia segons lʼacció que està realitzant lʼusuari. exportXML(): dona suport a la funcionalitat de desar planificacions en XML i és la continuació de la ja existent a la classe Board. Introdueix a un XML totes les dades de lʼactivitat i deriva a les transicions de les quals és origen per aconseguir també la seva informació i finalment retorna aquesta informació. 6.1.5 La classe Link La classe Link correspon exactament a la classe transició del model conceptual especificat i també del model de disseny, igualment que al cas anterior. A més a més també conté lʼelement gràfic de Flash necessari per representar una transició per pantalla i poder interaccionar amb ella. Concretament una transició es composa del seu punt dʼorigen i, en el cas de tenir punt de destí, una línia que comença al punt dʼorigen i acaba al punt destí. La classe gestiona principalment el comportament de les transicions i controla tota la informació que contenen. Aquesta classe, al igual que les activitats, tampoc té un bucle principal, ja que també és un element del model. Per tant es gestiona de forma similar a la classe anterior. 6.1.5.1 Atributs importants Id: correspon a un identificador numèric únic que tindrà cada transició a dins dʼuna activitat. Per tant, no poden haver dues transicions amb el mateix identificador que comencin a la mateixa activitat, això ens permet identificar cada transició inequívocament amb aquest atribut i lʼidentificador de lʼactivitat origen. activity: és un element que fa referència a lʼactivitat origen de la transició. Sʼinicialitza al crear la transició i no es pot modificar, ja que el punt dʼorigen ha dʼexistir sempre i no pot canviar dinàmicament. End: és un element que fa referència al punt destí de la transició. Al crear la transició és buit ja que no és necessari que existeixi un punt destí. Les 102 Assistent per desenvolupar videojocs en Flash transicions que no tenen punt destí es veuen gràficament només com a un punt dʼorigen sense línia dʼunió. mcPoint, mcLine i mcCode: contenen els MovieClips de Flash que té el disseny gràfic de la transició. Com totes les classes a la implementació dʼaquesta aplicació, tenim un element gràfic que es correspon amb ella. En aquest cas és un element compost, ja que hi han diferents elements gràfics independents. mcPoint correspon al punt dʼorigen que es mostrarà a les activitats. mcLine correspon a la línia que es veurà en cas que hi hagi una unió entre activitats i mcCode és un text que es mostra a la línia en cas que existeixi una condició. code i color: aquests són els atributs que pot editar lʼusuari i que es reflectiran de forma gràfica a lʼesquema visual de la planificació. El codi és un identificador de la condició que lʼusuari vol utilitzar en cas que el salt sigui condicional. Si la transició no és opcional el codi no serveix encara que existeixi. El color només varia lʼaspecte gràfic de la transició. 6.1.5.2 Funcions importants refreshMc(): serveix per actualitzar els elements gràfics dʼuna transició després de fer qualsevol canvi als seus atributs. També es crida directament des de la funció resfreshMc dʼactivitat a totes les transicions relacionades. insertEnd(...): quan lʼusuari interacciona a lʼàrea interactiva amb una transició i afegeix un punt de destí es crida a aquesta funció per indicar a la transició que sʼha dʼactualitzar el seu punt destí. select() i unselect(): actualitzen lʼestat gràfic de la transició, ja que el seu aspecte gràfic canvia segons lʼacció que està realitzant lʼusuari. exportXML(): dona suport a la funcionalitat de desar planificacions en XML i és la continuació de la ja existent a la classe Activity. Introdueix a un XML totes les dades de la transició i retorna aquesta informació. 103 Assistent per desenvolupar videojocs en Flash 6.1.6 La classe xmlPlayer La classe xmlPlayer correspon a la classe reproductor del model conceptual a lʼespecificació i al disseny. Inicialment estava pensada per reproduir planificacions a lʼeditor i fer així previsualitzacions. A la implementació sʼha decidit modificar lleugerament la classe per aconseguir un millor aprofitament del codi. Ja que moltes de les funcionalitats presents en aquesta classe seran després necessàries per implementar el mode dʼexecució. Per tant, aquesta classe reproductor sʼha transformat una mica i en lloc de reproduir simplement planificacions, el que fa es llegir una estructura de planificació en XML i reproduir-la. La única diferència és la utilització de XML, que ens facilitarà després la feina al mode dʼexecució. La classe conté la informació necessària per saber en tot moment quin és lʼactivitat que sʼestà reproduint, i també del mode dʼexecució que sʼestà utilitzant, és a dir, seqüencial o condicional. Sʼha de tenir en compte que el mode dʼexecució pot canviar al mig dʼuna planificació, per tant hi ha dʼhaver dues maneres similars però diferents de fer transicions entre activitats sense que lʼordre dʼexecució establert a la planificació sʼalteri. En aquest cas tampoc sʼha utilitzat un bucle principal encara que podria fer-se, però com no és un controlador i lʼestructura de càrrega i descàrrega contínua de fitxers SWF produeix molts esdeveniments, sʼha decidit estructurar la reproducció fent servir funcions de tipus observador que esperaran esdeveniments per fer la seva feina. Els esdeveniments que es poden produïr són bàsicament la càrrega i descàrrega dels fitxers i la finalització dʼuna reproducció, ja sigui pel compliment dʼuna condició o perquè sʼacabi lʼanimació. 6.1.6.1 Atributs importants xml: conté tota la informació de la planificació que es vol reproduir en format XML. Això ens permet aconseguir lʼobjectiu de poder després aprofitar la major part de lʼestructura dʼaquest reproductor per fer després el mode execució, ja que sʼhauran de llegir fitxers XML. swf i loader: són atributs interns del reproductor. El primer correspon al fitxer SWF que sʼestà reproduint i, per tant, és lʼelement gràfic de Flash que correspon al reproductor. El segon és un element de lʼAPI de Flash que 104 Assistent per desenvolupar videojocs en Flash permet carregar fitxers externs a lʼaplicació i que sʼutilitzarà per carregar els fitxers SWF. playList: és una llista dʼactivitats en XML tipus cua. A mida que el reproductor avança per lʼestructura de la planificació va omplint aquesta llista amb les activitats que sʼhan de reproduir i en lʼordre correcte. En cap cas sʼomple la llista amb activitats que depenen dʼuna condició fins que la condició sigui certa. Quan la reproducció dʼuna activitat acaba, es treu el primer element de la llista i es reprodueix. current: conté la informació en XML de lʼactivitat que sʼestà reproduint. Sʼutilitza sobre tot per accedir a la informació de totes les seves transicions i per accedir al nom del fitxer que sʼha de reproduir. 6.1.6.2 Funcions importants Play() i Stop(): la primera dʼaquestes funcions sʼencarrega dʼiniciar la reproducció dʼuna planificació. Carrega les dades en XML i comprova que el seu format sigui correcte i que existeixi alguna activitat per reproduir. En cas que tot sigui correcte llença la càrrega del primer fitxer SWF. La segona funció simplement atura la reproducció i buida el contingut gràfic del reproductor, així a lʼaplicació es tornarà a veure lʼàrea interactiva dʼedició. doneLoading(event): és una funció de tipus observador que sʼexecuta quan finalitza la càrrega dʼun fitxer SWF. Sʼencarrega dʼactualitzar el mode de reproducció abans de reproduir el fitxer SWF que sʼacaba de carregar, possa el fitxer carregat a reproduir i lʼafegeix al reproductor per a que es pugui veure a lʼaplicació. autoEnd(event): és una de les dues funcions que controlen la finalització dʼuna activitat. Aquesta només sʼactiva si el mode de reproducció és seqüencial, i a cada frame es comprova si sʼha arrivat al final de lʼanimació del swf. En cas que lʼactivitat sʼacabi sʼomple la llista de reproducció amb les següents activitats segons les transicions que tingui i es llença la càrrega del següent fitxer SWF a la llista. endCondition(...): és la segona funció que controla la finalització dʼuna activitat. funciona de manera similar a lʼanterior però només sʼactiva si el 105 Assistent per desenvolupar videojocs en Flash mode de reproducció és condicional. Quan es detecta la finalització es comprova quines de les transicions compleixen la condició i sʼafegeixen a la llista. 6.2 El mode execució: el joc Ara que ja existeix un mode per crear i editar planificacions, és necessari crear una manera dʼexecutar aquestes planificacions pels usuaris jugadors, que no tenen perquè saber que existeix lʼeditor ni han de necessitar saber-ho per utilitzar els resultats. Com ja sʼha comentat a lʼapartat anterior, el reproductor de planificacions que sʼha implementat facilita moltíssim la feina per fer això, ja que bàsicament sʼha de fer lo mateix que es fa al reproductor de lʼaplicació però transformant-lo en una altra aplicació independent, per tant, la gestió dʼaquest mode execució es redueix a utilitzar un controlador que gestionarà tot el joc, carregant el fitxer XML primer que conté la planificació, i després tindrà les mateixes funcions que utilitzava el reproductor de lʼaplicació per fer lʼexecució. Com a resultat dʼaixò tenim la classe Game. 6.2.1 La classe Game La classe Game correspon a la classe joc del model conceptual a lʼespecificació i al disseny. A la implementació serà una mena de fusió entre un controlador dʼaplicació i la classe xmlPlayer, ja que en realitat volem fer que el reproductor ara sigui una aplicació independent i que reprodueixi un fitxer XML extern. Per tant la diferència principal és que tindrem un fitxer de Flash associat a la classe Game igual que hi havia un altre associat a la classe flashAssistant. A més a més sʼhaurà de fer la càrrega dʼaquest fitxer XML que volem executar abans de començar la reproducció. En aquest cas no sʼexplicarà en detall el contingut de la classe ja que es tracta bàsicament dʼun xmlPlayer que funciona com una aplicació independent i, per tant, no cal tornar a explicar els mateixos punts descrits anteriorment. 106 Assistent per desenvolupar videojocs en Flash 7. Planificació temporal i anàlisi del cost En aquesta secció de la memòria es tracta de donar una visió general de la planificació que sʼha utilitzat per dur a terme el projecte. Al primer apartat es mostrarà un diagrama de Gantt que mostra totes les tasques realitzades al projecte i la duració de cadascuna. A partir dʼaquest diagrama podem extreure el temps exacte que es necessita per acabar el projecte i a partir dʼaquí es farà un anàlisi del cost del projecte. 7.1 Diagrama de Gantt Al diagrama de Gantt següent podem observar totes les tasques que sʼhan dut a terme durant el projecte. Aquestes tasques han estat agrupades segons a quina etapa del desenvolupament del projecte pertanyen. Les etapes del projecte són les següents: Tasques preliminars: es tracta del periòde de preparació del projecte i aprenentatge de les tecnologies clau per desenvolupar-lo. Anàlisi de requeriments: el primer anàlisi del projecte en profunditat que serveix per extreure les funcionalitats importants i els requisits necessaris pels usuaris. Especificació: anàlisi de lʼestructura del model conceptual de lʼaplicació i les tasques que cal fer a cadascun dels casos dʼús. Disseny: disseny de lʼaplicació tenint en compte les tecnologies que sʼhan dʼutilitzar i els patrons de disseny que es volen aplicar. Implementació: conté tot el període dʼimplementació de lʼaplicació, tant del mode edició com del mode execució, i de totes les proves necessàries. Realització de la memòria: temps dedicat a escriure la documentació del projecte. Preparació de la presentació: preparació dʼun tutorial i una demo per poder fer una presentació de lʼaplicació i fer una demostració del seu funcionament. 107 Assistent per desenvolupar videojocs en Flash Fig.7.1 Diagrama de Gantt. 108 Assistent per desenvolupar videojocs en Flash 7.2 Anàlisi del cost Lʼobjectiu dʼaquest apartat es fer una estimació del cost econòmic total que seria necessari per desenvolupar aquest projecte. Per fer això necessitarem fer un petit estudi dels recursos human, els recursos físics i el programari que han sigut necessaris pel desenvolupament dʼaquest projecte. Els recursos físics que sʼhan utilitzat per al desenvolupament del projecte són una conexió a Internet ADSL bàsica i un ordinador portàtil Macbook dʼApple. La conexió a Internet té un cost aproximat dʼuns 30 € al mes i un Macbook nou té un cost dʼuns 900 €, encara que el que sʼha utilitzat ja té tres anys i per tant, no seria necessari tenir en compte el seu cost total, ja que part del seu cost ja ha sigut amortitzat amb el temps. Per tant, dividirem el cost de lʼordinador pels seus mesos dʼutilització i només tindrem en compte el temps que sʼha utilitzat per a aquest projecte:" " 900 € / 36 mesos = 25 €/mes El programari utilitzat per desenvolupar el projecte no és lliure i, per tant, es necessari pagar una llicència per utilitzar-lo. El més important és lʼentorn de desenvolupament, és a dir, Flash CS5. El cost dʼuna llicència de Flash CS5 és dʼuns 520 €. El sistema operatiu utilitzat és Mac OS X Snow Leopard, però no tindrem en compte el seu cost perquè el cost del Macbook ja inclou el sistema operatiu. Per escriure la documentació del projecte sʼha utilitzat iWork 09, OmniGraffle per fer els diagrames i OmniPlan per fer el diagrama de Gantt. El cost dʼ iWork 09 és dʼuns 58 €, lʼOmniGraffle costa uns 75€ i lʼOmniPlan no té cost ja que no és necessari pagar llicència per utilitzar el programa un periode tan curt de temps. Maquinari i Programari Flash CS5 OmniGraffle OmniPlan iWork 09 Mac OS X Snow Leopard MacBook Conexió a Internet Mesos dʼús 6 2 0.1 2 8 8 8 Preu/mes €25.00 €30.00 Cost Total: Fig.7.2 Cost de maquinari i programari. 109 Cost €520.00 €75.00 €0.00 €58.00 €0.00 €200.00 €240 €1,093.00 Assistent per desenvolupar videojocs en Flash Per al càlcul dels recursos humans només sʼha tingut en compte la única persona que ha participat al projecte i que ha fet alhora el rol de cap de projecte, analista, dissenyador i programador. El cost mitjà per hora dʼun programador és de 40 € i, per tant, sʼha assignat aquest valor a les tasques de programació i documentació. A les tasques que corresponen a treball dʼanàlisi i disseny sʼha assignat un cost de 50 € perquè el cost mitjà dʼaquests rols és més alt. Tasques Tasques preliminars Anàlisi de requeriments Especificació Disseny Implementació Documentació Presentació Dies Hores/dia 23 13 16 21 61 40 7 4 4 4 4 4 4 4 Total: Hores totals Preu/hora 92 €40.00 52 €50.00 64 €50.00 84 €50.00 244 €40.00 160 €40.00 28 €40.00 724 Cost Total: Cost €3,680 €2,600 €3,200 €4,200 €9,760 €6,400 €1,120 €30,960 Fig.7.3 Cost de recursos humans. Si es suma el cost dels recursos humans (30,960 €) i el cost del maquinari i programari (1,093 €), el cost total del projecte és de 32,053 €. 110 Assistent per desenvolupar videojocs en Flash 8. Conclusions Lʼobjectiu principal del projecte sʼha assolit de forma satisfactòria. Aquest objectiu era desenvolupar una aplicació en Flash que permeti editar el flux dʼexecució dʼuna animació o aplicació Flash, composada per diferents fitxers de Flash, de forma gràfica i interactiva. A més aquest objectiu sʼhavia dʼassolir perquè lʼaplicació resultant pugui utilitzar-la un usuari que no tingui coneixements avançats de Flash o ActionScript. Lʼaplicació satisfà tots els requeriments funcionals que es van analitzar a lʼinici del projecte i també aconsegueix satisfer els requeriments no funcionals. Tot això sʼha aconseguit amb una interfície gràfica dʼusuari molt senzilla dʼutilitzar com es mostrarà al tutorial i la demostració i totes les funcionalitats funcionen dʼuna manera molt intuïtiva i interactiva per lʼusuari. Sʼhan pogut utilitzar amb èxit les tecnologies que es van proposar a lʼinici del projecte, encara que han proposat problemes a lʼhora dʼimplementar alguna de les funcionalitats sʼhan trobat alternatives viables per assolir els objectius més importants del projecte. La utilització dels fitxers XML ha facilitat molt la feina i ha donat alternatives a lʼhora dʼimplementar la funcionalitat de reproducció, que podria ser fins i tot ampliable al futur. La utilització de Flash CS5 amb totes les seves ajudes per treballar amb Flash ha facilitat també la feina en molts casos i és una eina bastant potent per a gairebé qualsevol objectiu a lʼhora de treballar amb Flash. Encara que encara és molt millorable lʼentorn per programar amb ActionScript. La implementació finalment sʼha pogut fer bastant fidel a la especificació i el disseny encara que sʼhan dut a terme petites modificacions per comoditat a lʼhora dʼimplementar. Algunes funcions del disseny a la implementació sʼhan trobat gairebé innecessàries i altres que no hi eren sʼhan hagut de fer per poder assolir amb èxit totes les funcionalitats proposades. Per fer aquest projecte sʼha intentat seguir una metodologia on poder aplicar els coneixements obtinguts al llarg de la carrera en desenvolupament de projectes i enginyeria del software. Tot això ha sigut una bona experiència a lʼhora de valorar la importància de planificar i analitzar les tasques dʼun projecte. 111 Assistent per desenvolupar videojocs en Flash Durant el projecte sʼha aprés a utilitzar una tecnologia molt actual com és Flash que no sʼutilitza durant la carrera i el seu llenguatge de programació, lʼActionScript 3, del qual no es tenia cap coneixement abans de començar el projecte. Ha sigut una experiència molt instructiva i positiva en aquest aspecte, ja que és una tecnologia amb moltíssimes possibilitats i que segurament tornaré a utilitzar en el futur. Encara que aquest projecte no està directament relacionat amb els videojocs, ja que podria considerar-se una aplicació bastant més general, sʼha enfocat al món dels videojocs Flash perquè és un tema molt interessant i, a més a més, personalment, els videojocs són una font dʼinspiració i una afició que mʼapassiona. Per tant treballar en una aplicació que pot servir per crear petits videojocs per persones que no tenen la possibilitat de fer-ho per manca de coneixements ha sigut una experiència molt positiva. Finalment, com a possibles millores de futur es podria afegir la possibilitat de poder programar amb més profunditat les transicions condicionals. També poder gestionar múltiples planificacions al mateix temps i afegir la possibilitat de carregar diferents tipus dʼobjectes a la planificació i no només fitxers de Flash, com podria ser so, imatges, vídeos o text. Tot això organitzat per capes, per exemple, per poder posar diferents elements executant-se al mateix temps, un vídeo amb text per sobre o una animació flash amb un so de fons. També es podria afegir la possibilitat dʼafegir efectes gràfics per representar les transicions durant lʼexecució, com es fa a alguns programes dʼedició de vídeo. 112 Assistent per desenvolupar videojocs en Flash 9. Bibliografia General: • • Google: www.google.com Wikipedia: http://es.wikipedia.org/wiki/Wikipedia:Portada XML: • • Manual dʼXML: http://www.w3schools.com/xml/xml_whatis.asp XML a ActionScript 3: http://www.republicofcode.com/tutorials/flash/as3xml/ Flash i ActionScript 3: • • • • • • Tutorials de Flash: http://www.cristalab.com/tutoriales/ Flash Developer Center: http://www.adobe.com/devnet/flash.html? view=quickstart Documentació de Flash: http://help.adobe.com/en_US/flash/cs/using/ index.html Tutorials dʼActionScript 3: http://www.flashandmath.com/ Learning ActionScript 3: http://help.adobe.com/en_US/as3/learn/ WS5b3ccc516d4fbf351e63e3d118a9b90204-8000.html Documentació dʼActionScript 3: http://livedocs.adobe.com/flash/9.0/ ActionScriptLangRefV3/ Programes utilitzats: • • Flash Player: http://www.adobe.com/products/flashplayer/ Flash CS5: http://www.adobe.com/products/flash/whatsnew/ • • • OmniGraffle: http://www.omnigroup.com/products/omnigraffle/ OmniPlan: http://www.omnigroup.com/products/omniplan/ iWork 09: http://www.apple.com/iwork/ 113