Desenvolupament dels jocs de taula Sator, Arepo i Tenet per la Nintendo DS

Títol: Desenvolupament dels jocs de taula Sator, Arepo i Tenet per la Nintendo DS Volum: 1/1 Alumne: Marc Salichs Pelegri Director/Ponent: Marc Vigo Anglada Departament: LSI Data: 23/01/09 DADES DEL PROJECTE Títol del Projecte: Desenvolupament dels jocs de taula Sator, Arepo i Tenet per la Nintendo DS Nom de l'estudiant: Marc Salichs Pelegri Titulació: Enginyeria Informàtica Crèdits: 37.5 Director/Ponent: Marc Vigo Anglada Departament: LSI – Llenguatges i Sistemes Informàtics MEMBRES DEL TRIBUNAL (nom i signatura) President: Antoni Soto Riera Vocal: Roque Meseguer Pallarés Secretari: Marc Vigo Anglada QUALIFICACIÓ Qualificació numèrica: Qualificació descriptiva: Data: Agraïments Vull agrair als meus pares i al meu germà tot el suport que m‟han donat durant el desenvolupament del PFC. També al Marc Vigo, el meu director de projecte, pel suport donat. Gracies també als amics, en especial a Rubén, Aleix i Toni, pel préstec del hardware necessari pel desenvolupament d‟aquest projecte. A tots moltes gràcies. i Índex Introducció . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1. Entorn de desenvolupament . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Hardware. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.1 Nintendo DS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.2 Mètodes per carregar aplicacions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Entorn de programació . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.1 Libnds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.2 PAlib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.3 Emuladors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Software general utilitzat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2. Anàlisis de requisits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 Requisits funcionals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Requisits no funcionals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3. Especificació . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Diagrames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 Jerarquia d‟actors participants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.2 Diagrama de casos d‟ús . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Especificació de casos d‟ús . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Model conceptual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4 Diagrames de navegació . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5 Story Boards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4. Disseny . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 Disseny de l‟arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.1 Arquitectura en capes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.2 Patró MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 7 8 8 9 10 11 11 12 13 15 15 17 19 19 19 20 24 40 41 42 45 45 46 47 ii 4.1.3 Patró plantilla i el llenguatge orientat a objectes . . . . . . . . . . . . . . . . 4.2 Diagrama de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 Capa de presentació . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1.1 Jocs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1.2 Menú . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1.3 Disseny gràfic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.2 Capa de domini . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.3 Capa de dades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Diagrames de seqüència . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5. Implementació . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1 Llenguatge de programació . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Metodologia biblioteca PAlib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3 Decisions d‟implementació . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4 Estructura del nostre sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.5 Estil de programació . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6. Intel·ligència Artificial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1 Teoria de jocs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Algoritme Minimax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3 Algoritme Minimax amb poda alfa-beta . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4 Altres modificacions de l‟algoritme Minimax . . . . . . . . . . . . . . . . . . . . . . 6.5 Heurístics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.6 Jocs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.6.1 Sator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.6.1.1 Successors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.6.1.2 Inicialització . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.6.1.3 Heurístic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.6.1.4 Profunditat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.6.2 Arepo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.6.2.1 Successors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.6.2.2 Heurístic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.6.2.3 Profunditat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.6.3 Tenet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.6.3.1 Successors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.6.3.2 Inicialització . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.6.3.3 Heurístic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 48 49 50 55 60 62 66 67 71 71 71 74 76 77 79 79 80 82 83 84 85 85 85 87 87 92 92 92 92 98 98 99 99 99 iii 6.6.3.4 Profunditat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.7 Consola Nintendo DS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7. Comunicació sense fils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.1 Biblioteca liblobby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2 Recepció de dades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3 Establiment de connexió . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4 Començant a jugar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4.1 Sator i Tenet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4.2 Arepo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5 Problemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8. Proves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1 Proves unitàries i d‟integració . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2 Proves de sistema i de validació . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3 Proves amb les intel·ligències artificials . . . . . . . . . . . . . . . . . . . . . . . . . . 8.4 Proves de la comunicació sense fils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.1 Objectius coberts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.2 Planificació final . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.3 Cost del projecte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.4 Modificacions futures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.5 Conclusions personals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Annex 1 Regles dels jocs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Arepo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tenet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Annex 2 Manual d’usuari . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Annex 3 Contingut del DVD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bibliografia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 100 103 103 104 105 106 107 108 108 111 112 112 112 113 115 115 116 117 118 118 119 119 120 121 125 133 135 6 Capítol 1 Entorn de desenvolupament 7 Capítol 1 Entorn de desenvolupament Un cop decidit que desenvoluparíem els jocs de taula Sator, Arepo i Tenet per la consola Nintendo DS, era necessari saber quines eines i aplicacions caldria tenir i configurar per dur terme el procés d‟implementació. Podíem escollir dues opcions: Utilitzar la SDK1 oficial de Nintendo. Utilitzar les SDK no oficials però de lliure distribució. Com és natural en aquests casos cal veure quins avantatges i quins inconvenients tenen cada una de les dues opcions, per finalment escollir-ne una o l‟altra. El primer punt a favor de les SDK no oficials, és el mètode en que es poden obtenir. Només cal accedir a través d‟Internet a les pàgines web oficials, i en pocs minuts tens tot el necessari per començar a configurar el teu entorn de desenvolupament per la consola. En canvi, si un vol accedir a una llicència oficial de Nintendo2, necessita seguir una sèrie de passos i complir alguns requisits [LLI]. En primer lloc cal posar-se en contacte amb les oficines de Nintendo Amèrica, ja que tenint en compte que seriem un desenvolupador en territori europeu és on ens hem de dirigir. Alguns dels requisits que ens demanen i que cal comentar són el següents:  S‟ha de tenir una empresa legalment formada i acreditar una seu d‟oficines on l‟empresa dur a terme la seva activitat. No considerant en cap cas una residencia particular com una oficina de treball.  Demostrar una certa experiència en el desenvolupament de jocs per videoconsoles dóna un plus extra a l‟hora de poder adquirir una llicència.  L‟adquisició del SDK comporta una despesa mínima de 2000$. Segurament els dos primers requisits poden ser més o menys flexibles un cop s‟està disposat a adquirir una llicència oficial, però la despesa necessària per obtenir-la és un inconvenient considerable. Es podria intentar demanar els recursos necessaris a la 1 Software Development Kit, inclou tot el software i hardware necessari pel desenvolupar per la consola 2 Una llicència oficial permet accedir al SDK oficial de Nintendo. Capítol 1 Entorn de desenvolupament 8 pròpia facultat, però creiem sincerament que només hagués produït un endarreriment considerable de l‟inici del projecte, obtenint finalment una negativa pels recursos demanats. Ara bé, si aconseguíssim una llicència oficial tindríem una sèrie de beneficis; disposaríem d‟una documentació completa de les funcionalitats de la consola, les eines que ens ajudarien en les tasques de debugging and testing, no esperaríem trobar cap tipus d‟incompatibilitat entre les funcionalitats, i segurament ens oferiria una major seguretat al tractar-se d‟un producte oficial que la pròpia Nintendo distribueix. En canvi si decidim escollir una SDK no oficial, ens podem trobar amb una falta de documentació rigorosa, no tenir la completa certesa de no poder-se trobar amb incompatibilitats o bugs en algunes de les funcionalitats que ofereix, no estar segur de poder utilitzar completament tots els recursos de la consola, i una dificultat elevada per mantenir en tot moment les últimes actualitzacions que aportin noves millores. Si en igualtat de condicions haguéssim d‟escollir una de les dues opcions, és obvi que obtenir una llicència oficial comporta molts més avantatges que no obtenir-la, però la despesa que aquesta comporta és un aspecte que fa desistir aquesta possibilitat. També hem de dir que ja teníem una predisposició clara en escollir un SDK no oficial, amb la qual cosa ja es partia d‟una decisió gairebé pressa. Cal esmentar, que un cop escollida l‟opció d‟utilitzar un SDK no oficial, la documentació que hem pogut trobar ha estat molt millor de la que es podria esperar en un principi [DOC], tot i que no suficientment actualitzada com un desitjaria. Els diferents manuals disponibles a la xarxa han estat un molt bon punt de partida per aquest Projecte i la gran comunitat homebrew3 existent per la consola Nintendo DS ha estat de gran ajuda a l‟hora de dur endavant el Projecte [HOM]. 1.1 Hardware Un cop decidit que no utilitzaríem una llicencia oficial cal comentar quin és el hardware necessari que necessitarem per poder executar el nostre joc. 1.1.1 Nintendo DS. Passarem a comentar algunes característiques del hardware de la videoconsola NDS que són necessàries conèixer a l‟hora de desenvolupar qualsevol tipus d‟aplicació: 3 Comunitat d‟aficionats que podem trobar a la xarxa que s‟encarrega de desenvolupar aplicacions informàtiques que tenen com a objectiu poder-se executar sobre videoconsoles propietàries. Capítol 1 Entorn de desenvolupament 9 Figura 1. 1 Consola Nintendo DS Lite  -Pantalles: dues pantalles de 3 polsades TFT/LCD amb una resolució de 256x192 píxels. Són capaces de mostrar fins a 260.000 colors i la pantalla inferior és tàctil.  -Controls: Controls digitals que inclouen la creueta de direcció, els botons d‟acció (A,B,X,Y, L,R), i el botó Start i el Select. També tenim a la nostre disposició el control mitjançant la pantalla tàctil.  Processadors: dos processadors ARM: un ARM9 principal a 67 MHz i un coprocessador ARM7 a 33Mhz. Disposa de 4MB de memòria RAM.  So: 2 altaveus estèreo.  Comunicació sense fils: compatible amb 802.11 i amb un protocol de comunicació de Nintendo.  Micròfon: La consola porta incorporat un petit micròfon. Pel tipus de joc que desenvoluparem no ens serà necessari.  Gràfics: Capacitat per mostrar gràfics en 2D i 3D. En l‟actualitat ha sortit una tercera versió de la consola Nintendo DS, anomenada Nintendo DSi, que incorpora diverses novetats respecta les seves predecessores, però que no s‟han tingut en compte en el desenvolupament d‟aquest projecte. 1.1.2 Mètodes per carregar aplicacions Les consoles actuals no permeten executar aplicacions desenvolupades per nosaltres que no hagin estat signades per empreses desenvolupadores. Per tant es fa necessari disposar d‟algun tipus de mètode per poder-les executar en la nostra consola Nintendo DS. Capítol 1 Entorn de desenvolupament 10 L‟evolució dels mètodes per carregar software ha millorat moltíssim en els últims dos anys, i s‟han deixat enrere els complicats i perillosos mètodes que requerien actualitzar el firmware de la consola. En l‟actualitat només ens cal disposar d‟un dels diferents cartutxos flash disponibles en botigues especialitzades per poder executar les nostres aplicacions. Existeixen diferents opcions actualment en el mercat, però les que hem utilitzat en el desenvolupament del projecte són les que es poden veure a la figura 1.2. Figura 1. 2 Targetes flash disponibles R4 / M3 Simply / SuperCard Ds / SuperCard Ds One No hi ha cap targeta més recomanable que una altra, ja que totes elles executen de forma correcta el joc que s‟adjunta en aquesta memòria. Hem de comentar que existeixen sistemes més antics que poden requerir la utilització del DLDI Pathcer4 per poder utilitzar les capacitats de guardat de partida del nostre joc. 1.2 Entorn de programació Un cop decidit que utilitzarem un SDK no oficial, necessitem instal·lar i configurar tot una sèrie d‟eines i aplicacions que ens permetran preparar tot l‟entorn de programació. Principalment existeixen dues biblioteques lliures, les libnds i les PAlib, totes dues incloses en el devkitPro5 així com els compiladors i altres utilitats necessàries pel desenvolupament d‟aplicacions per la consola Nintendo DS. Com aquest document no pretén ser un manual d‟usuari deixarem de banda aspectes relacionats amb la configuració de l‟entorn de programació (variables d‟entorn, fitxers a descarregar, directoris d‟instal·lació) ja que es pot trobar la documentació pertinent en [DOC]. Per tant dedicarem aquest apartat exclusivament a parlar sobre les biblioteques que podem trobar i quines altres aplicacions seran utilitzades en el transcurs del projecte. 4 Aplicació que permet activar la capacitat d‟escriptura i lectura de fitxer externs en aplicacions desenvolupades per la consola Nintendo DS. 5 Un paquet software que incorpora totes les eines necessàries pel desenvolupament de diverses consoles com la Game Cube, GP32, Nintendo DS o la PSP Capítol 1 Entorn de desenvolupament 11 1.2.1 Libnds Anteriorment coneguda com ndslib, és la biblioteca estàndard pel desenvolupament per la consola Nintendo DS i la primera en ser una alternativa seriosa al SDK oficial. És possible programar totes les característiques de la consola; pantalla tàctil, botons digitals, reproducció de so, efectes sonors, interrupcions, fons de pantalla i gràfics 2D/3D. Utilitza un nivell d‟abstracció baix, sent possible treballar amb els propis registres de la consola, donant una amplia flexibilitat a l‟hora de desenvolupar aplicacions. El principal inconvenient recau en el seu baix nivell d‟abstracció, ja que per implementar elements bàsics calen definir molts aspectes de la consola. Es pot obtenir més informació a [LIB]. 1.2.2 PAlib És la biblioteca que hem decidit utilitzar en el nostre projecte i l‟alternativa més seriosa a les libnds [PAL]. Utilitza com a base la pròpia libnds però oferint un nivell d‟abstracció superior en les seves funcionalitats. D‟aquesta manera facilita considerablement la programació respecte la libnds, ja que no requereix un coneixement tant precís del hardware de la consola per utilitzar-la. A més a més facilita considerablement programar aspectes gràfics per la consola. La biblioteca s‟actualitza a mesura que la pròpia comunitat homebrew hi introdueix canvis, ja es tracti de petites actualitzacions per corregir-ne errors puntuals, a actualitzacions de pes en que s‟incorporen noves funcionalitats. Les últimes actualitzacions s‟han inclòs una sèrie de noves biblioteques que n‟augmenten considerablement les funcionalitats:  mikmod: amplia les funcionalitats del sintetitzador que la biblioteca PAlib porta incorporat. Permet reproduir arxius en format s3m, it, XM a més a més dels arxius mod6.  liblobby: conté totes les funcionalitats necessàries per la implementació d‟una connexió sense fils entre dues o més consoles Nintendo DS. És precisament la biblioteca que utilitzarem en el nostre joc.  efs Lib: millora les funcionalitats existents per la lectura i escriptura de fitxers externs. 6 Formats d‟àudio que no contenen música gravada, sinó un conjunt d‟instruccions que indiquen al reproductor com ha de tocar un so. Capítol 1 Entorn de desenvolupament 12  ASlib: millora considerablement el reproductor de música incorporat en la biblioteca PAlib. Permet reproduir arxius en format mp3 o wav. Conjuntament a aquestes biblioteques, el propi paquet devkitPro incorpora una sèrie d‟aplicacions que ens seran de gran utilitat a l‟hora d‟utilitzar les biblioteques PAlib pel desenvolupament per la consola:  PAGfx: Aplicació que permet convertir qualsevol imatge en format bmp, gif, jpg, jpeg o png, a un format comprensible per la consola. En serà indispensable pel nostre projecte, ja que l‟utilitzarem per convertir totes les imatges que utilitzarem.  VHAM: IDE7 que utilitzarem per programar.  dsFont: Aplicació que converteix qualsevol tipus de lletra a un mapa de bits que serà utilitzat per personalitzar les fonts que utilitzarem en el nostre joc.  Gif2Frames: Converteix qualsevol animació en format gif en una llista d‟imatges que es poden utilitzar posteriorment per implementar animacions frame a frame8 en el joc.  ImageSplitter: Divideix una imatge de més de 64x64 píxels, en subimatges d‟aquesta grandària per poder-les utilitzar en el nostre joc en forma de sprites9. 1.2.3 Emuladors Si volem executar les nostres aplicacions desenvolupades per la consola Nintendo DS sense necessitat d‟utilitzar la pròpia consola, disposem d‟una amplia varietat d‟emuladors a la xarxa. El principal problema de tots ells es que no emulen correctament certes funcionalitats de la consola. És el cas de l‟escriptura en fitxers externs o la comunicació sense fils. Això implica que per provar aquestes funcionalitats concretes caldrà utilitzar la consola obligatòriament Un altre inconvenient que presenten els emuladors, amb l‟excepció del NO$GBA [GBA], és que no emulen completament algunes funcionalitats bàsiques de la consola; és el cas de la utilització de tipus de lletra personalitzats. També ens trobem en que presenten seriosos problemes de velocitat en executar la majoria de jocs, 7 Integrated Development Environment (Entorn de desenvolupament integrat), o programa que s‟utilitzarà per codificar i compilar el codi del nostre joc. 8 Animació feta imatge a imatge 9 Gràfic que es presenta en el joc amb característiques pròpies com l‟estat, posició o moviment. S‟utilitza per representar elements mòbils o interactius en els jocs com els botons o els protagonistes. Capítol 1 Entorn de desenvolupament 13 impossibilitant jugar-hi correctament a causa de lentitud de la resposta i pel baix framerate10 al que funcionen. Durant el desenvolupament d‟aquest projecte s‟ha utilitzat exclusivament l‟emulador NO$GBA per aquest motiu. Existeixen altres emuladors com el iDeaS, el NeonDS o el DeSmuMe, que tot i que poden ser utilitzats per comprovar petites aplicacions, es tornen inservibles quan es vol executar algun joc a un framerate constant o en provar algunes funcionalitats concretes. 1.3 Software general utilitzat En aquest apartat ens centrarem en quin altre software hem utilitzat durant el desenvolupament del projecte :  Switch: Aplicació que ens permet convertir qualsevol tipus d‟arxiu de so, al format raw que utilitzarem en el nostre joc.  ModTracker: aplicació que permet modificar arxius de música en format mod [MOD]. L‟utilitzarem per realitzar algunes modificacions; com la disminució del volum o instruccions de salt per incorporar un reproducció cíclica en les nostres músiques.  Photoshop CS2: S‟utilitzarà per la creació de tot l‟apartat gràfic del joc.  Microsoft Visio: S‟utilitzarà per crear tots els diagrames UML i de seqüències.  Microsoft Word: Editor de text que utilitzarem per redactar aquesta memòria. 10Freqüència de repintat d‟imatges en pantalla. La consola Nintendo DS actualitza la pantalla 60 cops per segon (fps), mentre que alguns emuladors executen els jocs a 25-30 fps. 14 Capítol 2 Anàlisis de requisits 15 Capítol 2 Anàlisi de requisits Els requisits d‟un sistema software s‟encarreguen de descriure les funcionalitats i el comportament que aquest ha de tenir. Diferenciem entre dos tipus de requisits:  Funcionals: Defineixen les funcionalitats que el nostre sistema ha de tenir. Són els encarregats de dir-nos què ha de fer el nostre sistema.  No funcionals: Especifiquen criteris que poden utilitzar-se per jutjar el comportament del nostre sistema més enllà del les funcionalitats que ofereix. Es descriuen propietats com la fiabilitat, rendiment, temps de resposta i el tipus d‟aparença que desitgem que la nostra aplicació tingui. 2.1 Requisits funcionals Funcionalitats de gestió de partides: -El sistema hauria de permetre crear un perfil d‟usuari on s‟emmagatzemi el nom de l‟usuari, la data de creació, la data de l‟última partida, i les victòries, derrotes i empats aconseguits en cada un dels joc. -El sistema hauria de permetre a l‟usuari esborrar una partida prèviament creada. -El sistema hauria de permetre a l‟usuari carregar les dades d‟una partida prèviament creada. -El sistema hauria de permetre consultar la informació completa de la partida carregada. Informació del sistema: -El sistema hauria de permetre visualitzar les regles de cada un dels jocs. -El sistema hauria de permetre visualitzar qui ha creat el joc. Capítol 3 Especificació 22 Crear una partida Wifi Buscar una partida Wifi «uses» Jugar una partida Wifi User JugadorWifiHost JugadorWifiUser Iniciar una partida al Sator Wifi Iniciar una partida a l'Arepo Wifi Iniciar una partida al Tenet Wifi «uses» «uses» «uses» Figura 3. 5 Diagrama de casos d’ús Iniciar una partida per l’actor JugadorWifi Jugant: Jugador Inicialitzar configuració fitxes Sator Moure fitxa Sator Moure fitxa Arepo JugadorWifi Figura 3. 6 Diagrama de casos d’ús Jugant.1 Capítol 3 Especificació 23 Jugador Inicialitzar configuració fitxes Tenet Moure fitxa Tenet Escollir carta JugadorWifi Jugador Wifi Host Figura 3. 7 Diagrama de casos d’us Jugant.2 Menú de pausa Menú de resultat Jugador JugadorWifi Host Figura 3. 8 Diagrama de casos d’us Jugant.3 Capítol 3 Especificació 24 3.2 Especificació de casos d’ús Un cop identificats els diferents casos d‟ús, l‟especificació ens permet definir-ne el comportament mitjançant el possible conjunt missatges que s‟intercanviaran els actors i el sistema. Abans de començar amb la descripció de cada un dels casos d‟ús mostrem la plantilla que utilitzarem per tots ells: - Nom del cas d’ús Descripció: Propòsit o finalitat del cas d‟ús Actors: Actors participants en el cas d‟ús Precondicions: Condicions que s‟han de complir a l‟inici de l‟execució del cas d‟ús Curs típic d’esdeveniments Actor Sistema -1. Acció 1 -2. Acció 2 -4.Execució d’un cas d’us inclòs en el sistema -5. Acció 3 -3.Resposta del sistema 1 Curs alternatiu 3a. Es produeix una circumstancia en el punt 3 que modifica el curs típic d‟esdeveniments 3a1 Actuació 1 3a2 Actuació 2 3a21 Actuació 1 3a22 Actuació 2 Postcondicions: Condicions que s‟han de complir a l‟acabar l‟execució del cas d‟ús Taula 3.1 Plantilla d’exemple dels casos d’ús. Capítol 3 Especificació 25 1.Crear una Partida Descripció: Permet a l‟usuari crear una nova partida pel joc Actors: Jugador Precondicions: - Curs típic d’esdeveniments Actor Sistema 1. L‟actor selecciona una ranura lliure per crear una partida. 2. L‟actor notifica que vol crear una nova partida. 4. L‟actor introdueix el nom de la nova partida 3.El sistema mostra la pantalla per crear un nova partida 5.El sistema crea i emmagatzema la nova partida Curs alternatiu 4a. L‟actor no vol crear una nova partida 4a1 L‟actor notifica al sistema que no vol crear una nova partida 4a2 Acabar el cas d‟ús. 5a. El nom introduït no és un nom vàlid 5a1 El sistema notifica a l‟actor que ha introduït un nom no vàlid 5a2 L‟actor introdueix un altre nom Postcondicions: S‟ha creat una nova partida en el sistema 2.Esborrar una Partida Descripció: Permet a l‟usuari esborrar una partida Actors: Jugador Precondicions: Existeix la partida que es vol esborrar Curs típic d’esdeveniments Actor Sistema 1. L‟actor selecciona la partida que vol esborrar. 2. L‟actor notifica que vol esborrar la partida seleccionada. 4. L‟actor confirma que desitja esborrar la partida 3. El sistema mostra una pantalla per confirmar que l‟actor vol esborrar la partida 5. El sistema esborra la partida del sistema Curs alternatiu 4a. L‟actor canvia d‟opinió i no vol esborrar la partida 4a1 L‟actor notifica al sistema que no desitja esborra la partida Capítol 3 Especificació 26 4a2 Acaba el cas d‟ús. Postcondicions: S‟ha esborrat la partida Postcondicions curs alternatiu: - 3.Carregar una partida Descripció: Permet carregar una partida creada per començar a jugar Actors: Jugador Precondicions: Existeix la partida que es vol carregar Curs típic d’esdeveniments Actor Sistema 1. L‟actor selecciona la partida que vol carregar. 2. L‟actor notifica que vol carregar la partida seleccionada. 3. El sistema carrega les dades de la partida. Curs alternatiu Postcondicions: S‟han carregat les dades de la partida 4.Consultar estadístiques de la partida Descripció: Permet consultar les estadístiques de la partida carregada Actors: Jugador Precondicions: Les dades de la partida s‟han hagut de carregar anteriorment Curs típic d’esdeveniments Actor Sistema 1. L‟actor selecciona que vol veure les estadístiques de la partida actual 2. El sistema mostra les estadístiques de la partida actual. Curs alternatiu - Postcondicions: - 5. Consultar regles Sator Descripció: Permet consultar les regles del joc Sator Actors: Jugador Precondicions: - Curs típic d’esdeveniments Actor Sistema Capítol 3 Especificació 27 1. L‟actor indica al sistema que vol veure les regles del joc Sator. 2. El sistema mostra les regles del joc Sator Curs alternatiu Postcondicions: - 6. Consultar regles Arepo Descripció: Permet consultar les regles del joc Arepo Actors: Jugador Precondicions: - Curs típic d’esdeveniments Actor Sistema 1. L‟actor indica al sistema que vol veure les regles del joc Arepo 2. El sistema mostra les regles del joc Arepo Curs alternatiu Postcondicions: - 7. Consultar les Regles Tenet Descripció: Permet consultar les regles del joc Tenet Actors: Jugador Precondicions: - Curs típic d’esdeveniments Actor Sistema 1. L‟actor indica al sistema que vol veure les regles del joc Tenet. 2. El sistema mostra les regles del joc Tenet Curs alternatiu Postcondicions: - 8. Consultar crèdits Descripció: Permet consultar els crèdits del joc Actors: Jugador Precondicions: - Capítol 3 Especificació 28 Curs típic d’esdeveniments Actor Sistema 1. L‟actor selecciona l‟opció de veure els crèdits del joc. 2. El sistema mostra els crèdits del joc. Curs alternatiu Postcondicions: - 9. Configurar partida Sator. Descripció: Permet configurar una partida al joc Sator Actors: Jugador Precondicions: - Curs típic d’esdeveniments Actor Sistema 1. L‟actor selecciona que vol fer una partida individual. 3. L‟actor escull el joc Sator 5. L‟actor selecciona si vol començar amb les fitxes blanques o les negres i si vol que s‟alterni el color de les fitxes en cada nova partida. 2. El sistema mostra per pantalla els jocs disponibles Sator, Arepo i Tenet. 4. El sistema mostra per pantalla les opcions de configuració del Sator 6. El sistema guarda les dades escollides i la partida està preparada per començar. Curs alternatiu 1a. L‟actor decideix que vol realitzar una partida multi jugador 1a1 L‟actor notifica que vol realitzar una partida multi jugador 1a2 El sistema mostra les opcions per realitzar una partida multi jugador 1a2a1 L‟actor notifica que vol realitzar una partida multi jugador en una mateixa consola 3a. L‟actor decideix que no vol realitzar una partida individual. 3a1 L‟actor notifica al sistema que no desitja fer una partida individual. 3a2 Es torna al punt 1. 5a. L‟actor decideix que no vol configurar una partida pel joc Sator. 5a1 L‟actor notifica al sistema que no desitja fer una partida amb el joc Sator. 5a2 El sistema torna al punt 2. Postcondicions: S‟ha configurat una partida pel joc Sator Postcondicions curs alternatiu: - Capítol 3 Especificació 29 10. Iniciar partida Sator. Descripció: Permet iniciar una partida al joc Sator Actors: Jugador Precondicions: - Curs típic d’esdeveniments Actor Sistema 1. Configurar partida al Sator 2. L‟actor decideix que vol iniciar la partida al joc Sator. 3. El sistema inicia el joc Sator Curs alternatiu 2a. L‟actor decideix que no vol iniciar una partida amb les opcions configurades 2a1 L‟actor notifica al sistema que no desitja fer una partida al Sator amb les opcions escollides 2a2 Es torna al punt 1. 2b. L‟actor decideix que vol veure les regles del joc Sator. 2b1 Consultar Regles Sator Postcondicions: Comença una partida al joc Sator Postcondicions curs alternatiu: - 11. Configurar partida Arepo. Descripció: Permet configurar una partida al joc Arepo Actors: Jugador Precondicions: - Curs típic d’esdeveniments Actor Sistema 1. L‟actor selecciona que vol fer una partida individual. 3. L‟actor escull el joc Arepo 5. L‟actor selecciona les regles de la partida i la disposició dels jugadors en ella. 2. El sistema mostra per pantalla els jocs disponibles Sator, Arepo i Tenet. 4. El sistema mostra per pantalla les opcions de configuració del Arepo 6. El sistema guarda les dades escollides i la partida està apunt de començar Curs alternatiu 1a. L‟actor decideix que vol realitzar una partida multi jugador 1a1 L‟actor notifica que vol realitzar una partida multi jugador 1a2 El sistema mostra les opcions per realitzar una partida multi jugador 1a2a1 L‟actor notifica que vol realitzar una partida multi jugador en una mateixa consola Capítol 3 Especificació 30 3a. L‟actor decideix que no vol realitzar una partida individual. 3a1 L‟actor notifica al sistema que no desitja fer una partida individual. 3a2 Es torna al punt 1. 5a. L‟actor decideix que no vol configurar una partida pel joc Arepo. 5a1 L‟actor notifica al sistema que no desitja fer una partida amb el joc Arepo. 5a2 El sistema torna al punt 2. Postcondicions: S‟ha configurat una partida pel joc Arepo Postcondicions curs alternatiu: - 12. Iniciar partida Arepo Descripció: Permet iniciar una partida al joc Arepo Actors: Jugador Precondicions: - Curs típic d’esdeveniments Actor Sistema 1. Configurar partida Arepo 2. L‟actor decideix que vol iniciar la partida al joc Arepo. 3. El sistema inicia el joc Arepo Curs alternatiu 2a. L‟actor decideix que no vol iniciar una partida al joc Arepo 2a1 L‟actor notifica al sistema que no desitja fer una partida al joc Arepo. 2a2 Es torna al punt 1. 2b. L‟actor decideix que vol veure les regles pel joc Arepo. 2b1 Consultar Regles Arepo Postcondicions: Comença una partida al joc Arepo Postcondicions curs alternatiu: - 13. Configurar partida Tenet Descripció: Permet configurar una partida al joc Tenet Actors: Jugador, JugadorHost Precondicions: - Curs típic d’esdeveniments Actor Sistema 1. L‟actor selecciona que vol fer una partida Individual. 3. L‟actor escull el joc Tenet 5. L‟actor selecciona si vol començar amb fitxes blanques o negres, si vol que el 2. El sistema mostra per pantalla els jocs disponibles Sator, Arepo i Tenet. 4. El sistema mostra per pantalla les opcions de configuració del Tenet Capítol 3 Especificació 31 color de les fitxes es vagi alternant, i si desitja configurar una posició inicial de fitxes diferent a la predeterminada. 6. El sistema guarda les dades escollides i la partida està apunt de començar Curs alternatiu 1a. L‟actor decideix que vol realitzar una partida multi jugador 1a1 L‟actor notifica que vol realitzar una partida multi jugador 1a2 El sistema mostra les opcions per realitzar una partida multi jugador 1a2a1 L‟actor notifica que vol realitzar una partida multi jugador en una mateixa consola 3a. L‟actor decideix que no vol realitzar una partida individual. 3a1 L‟actor notifica al sistema que no desitja fer una partida individual. 3a2 Es torna al punt 1. 5a. L‟actor decideix que no vol configurar una partida pel joc Tenet 5a1 L‟actor notifica al sistema que no desitja fer una partida amb el joc Tenet. 5a2 El sistema torna al punt 2. Postcondicions: S‟ha configurat una partida pel joc Tenet Postcondicions curs alternatiu: - 14. Iniciar partida Tenet Descripció: Permet iniciar una partida al Tenet Actors: Jugador Precondicions: - Curs típic d’esdeveniments Actor Sistema 1. Configurar partida Tenet 2. L‟actor decideix que vol iniciar la partida al joc Tenet. 3. El sistema inicia el joc Tenet Curs alternatiu 2a. L‟actor decideix que no vol iniciar una partida al joc Tenet 2a1 L‟actor notifica al sistema que no desitja fer una partida al joc Tenet 2a2 Acaba el cas d‟ús. 2b. L‟actor decideix que vol veure les regles pel joc Tenet. 2b1 Consultar Regles Tenet Postcondicions: Comença una partida al joc Tenet Postcondicions curs alternatiu: - 15. Crear una partida Wifi Descripció: Permet crear una partida per poder jugar als diferents jocs utilitzant una comunicació sense fils. Actors: JugadorHost Precondicions: - Capítol 3 Especificació 38 3a2 El sistema notifica a l‟actor que no pot moure la fitxa en aquella posició 3a3 Es torna al punt 1. 6a. El sistema comprova que encara queden fitxes per situar 6a1 El sistema notifica a l‟actor que no pot començar la partida 6a2 Es torna al punt 1. 6b. L‟actor participant és un JugadorHost 6b1 El sistema envia a l‟altre usuari la configuració inicial escollida. Postcondicions: S‟ha inicialitzat correctament la posició de les fitxes 25. Escollir carta Tenet Descripció: Permet escollir una carta en el Tenet Actors: Jugador, JugadorWifi Precondicions: A l‟actor actual li toca tirar, i pot realitzar algun moviment Curs típic d’esdeveniments Actor Sistema 1. L‟actor selecciona una carta 2. El sistema actualitza l‟estat i mostra la carta marcada Curs alternatiu Postcondicions: L‟actor ha seleccionat una carta 26.Moure una fitxa Tenet Descripció: Permet moure una fitxa en el tauler Actors: Jugador, JugadorWifi Precondicions: A l‟actor actual li toca tirar, i pot realitzar algun moviment Curs típic d’esdeveniments Actor Sistema 1. Cas d’ús Escollir carta Tenet 2. L‟actor selecciona una fitxa 4. L‟actor mou la fitxa cap a una posició. 3. El sistema mostra per pantalla les posicions on pot moure la fitxa 5. El sistema actualitza l‟estat Curs alternatiu 1a. L‟actor utilitza la carta escollida per defecte. 1a1 Es passa al punt 2. 2a. El sistema comprova que la carta seleccionada no és una carta vàlida per la fitxa seleccionada. 2a1 El sistema notifica a l‟actor que no hi ha posicions on pot moure la fitxa. 2a2 Es torna al punt 1. 3a. L‟actor mou la fitxa cap a una posició no vàlida 3a1 L‟actor mou la fitxa a una posició no vàlida Capítol 3 Especificació 39 3a2 El sistema notifica a l‟actor que no pot moure la fitxa en aquella posició 3a3 Es torna al punt 2. Postcondicions: L‟usuari ha mogut una fitxa i utilitzat una carta. 27.Menú de pausa Descripció: Permet a l‟usuari reiniciar o sortir de la partida actual Actors: Jugador, JugadorHost Precondicions: A l‟actor actual li toca tirar Curs típic d’esdeveniments Actor Sistema 1. L‟actor prem el botó Start 3. L‟actor selecciona l‟opció de sortir 2. El sistema mostra per pantalla el menú de Pausa. 4. El sistema finalitza la partida Curs alternatiu 3a. L‟actor vol reiniciar la partida. 3a1 L‟actor selecciona l‟opció reiniciar 3a2 El sistema reiniciar la partida 3b. L‟actor vol continuar la partida. 3b1 L‟actor selecciona l‟opció continuar. 3b2 El sistema continua la partida. 4a. Si l‟actor és el JugadorHost 4a1 El sistema envia a l‟altre usuari la opció escollida. Postcondicions: - 28.Menú de resultat Descripció: Mostra el resultat de la partida actual i permet a l‟usuari sortir de la partida Actors: Jugador, JugadorHost Precondicions: La partida ha finalitzat i s‟han mostrar qui es el guanyador Curs típic d’esdeveniments Actor Sistema 1. L‟actor selecciona Sortir de la partida 2. El sistema finalitza la partida Curs alternatiu 1a. L‟actor vol reiniciar la partida. 1a1 L‟actor selecciona l‟opció reiniciar 1a2 El sistema reiniciar la partida 2a. Si l‟actor és el JugadorHost 2a1 El sistema envia a l‟altre usuari la opció escollida. Postcondicions: - Capítol 3 Especificació 40 3.3 Model conceptual El model conceptual servirà per proporcionar una idea de l‟estructura interna del nostre sistema. El disseny final de les classes participants i dels seus mètodes agafarà la seva forma definitiva en la fase de disseny, per tant aquest primer model conceptual ens servirà com a punt de partida pel disseny de la nostra aplicació. -jugador : s8 -board[] : s8 -numFitxes : s8 -numCeles : s8 Estat -mortesP1 : s8 -mortesP2 : s8 EstatArepo -mortesBlanquesP1 : s8 -mortesBlanquesP2 : s8 -mortesVermellesP1 : s8 -mortesVermellesP2 : s8 EstatSator -idCartaP1 : s8 -idCartaP2 : s8 -mortesP1 : s8 -mortesP2 : s8 -mortesCartesP1 : s8 -mortesCartesP2 : s8 EstatTenet -idFitxa : s8 -posicioF : posicio -morta : bool Fitxa -color : ColorFitxa -visible : bool FitxaSator -numCartes : s8 -tipus : TipusTenet FitxaTenet FitxaArepo -idCarta : s8 -morta : bool -tipusCarta : TipusTenet -tipusMoviment : TipusTenet Carta 1 1..5 110 1 10 +X : s16 +Y : s16 «struct» posicio +BLANCA +VERMELL +NOCOLOR «enumeration» ColorFitxa +REI +CAVALL +ALFIL +TORRE +DAMA «enumeration» TipusTenet -screen -partida -joc -player1 : char -player2 : char -player3 : char -player4 : char -alternar : bool -color -iniciar : bool -numPlayers -regles -dis -activat : bool -idPlayer Game -idSlot : int -nomPartida[] : char -dataCreacio[] : char -dataUltimaPartida[] : char -valors[] : int infoPartidaSalvada 1 1...3 Restriccions d’integritat:  No hi pot haver dues fitxes amb el mateix identificador  No hi pot haver dues cartes amb el mateix identificador  No hi pot haver dos infoPartidaSalvada amb el mateix idSlot. Capítol 3 Especificació 41 3.4 Diagrames de navegació Un cop especificats els casos d‟ús del nostre sistema podem mostrar un diagrama en el que es representin les diferents pantalles que tindrem. Aquestes pantalles en serviran per accedir al diferents casos d‟ús descrits. Hem d‟especificar que en aquest punt ja s‟ha tingut en compte que estàvem dissenyant un joc per la consola Nintendo DS. La metodologia dels menús que segueixen la majoria de jocs per la consola, acostumen a seguir sempre unes pautes predefinides i a mostrar un conjunt de pantalles molt semblants. Basant-nos en aquestes pautes i en les pròpies funcionalitats descrites en els casos d‟ús, hem dissenyat el nostre sistema de pantalles que es pot veure a la figura 3.9 i 3.10. Pantalla Logo Principal Selecció partida Crear partida Esborrar partida Selecció mode de joc Selecció joc Individual Partida Multijugador Informació partida Crèdits Figura 3. 9 Sistema de menús 1 Selecció joc Individual Partida Multijugador Selecció Joc Multiplayer en una mateixa consola Selecció crear o buscar partida sense fils Opcions joc Sator Opcions joc Arepo Opcions joc Tenet Iniciar partida Regles joc Opcions joc Sator Opcions joc Arepo Opcions joc Tenet Crear partida Wifi Buscar partida Wifi Esperar dades Opcions joc Sator Opcions joc Arepo Opcions joc Tenet Iniciar partida Wifi Començar Joc Figura 3. 10 Sistema de menús 2 Capítol 3 Especificació 42 I també mostrem les diferents pantalles que podem tenir mentre estem jugant en cada un dels diferents jocs del sistema. Joc Pausa No pot moure Resultat Esperant Dades Figura 3. 11 Sistema de pantalles durant una partida Hem de dir que la pantalla No pot moure va ser incorporada en fases posteriors del projecte, ja que es va veure convenient mostrar de forma explícita quan un jugador no pot moure cap de les seves fitxes. 3.5 Story Boards Un cop dissenyada la navegació i les diferents pantalles que tindrem en el nostre joc, cal començar-ne a fer els primers esbossos per veure com distribuirem els diferents elements interactius a les diferents pantalles: Figura 3. 12 Esbós pantalla principal / selecció mode Figura 3. 13 Esbós pantalla save data Capítol 3 Especificació 43 Figura 3. 14 Esbós selecció joc / menú de pausa Figura 3. 15 Iniciar partida / finestra superior 44 Capítol 4 Disseny 45 Capítol 4 Disseny En el capítol anterior hem aconseguit identificar tant el problema a resoldre com les necessitats i funcionalitats que ha de satisfer el nostre sistema a desenvolupar. En aquesta etapa hem d‟anar un pas més enllà i respondre a la pregunta cóm ho hem de fer?. L‟etapa de disseny s‟encarrega d‟aplicar diferents tècniques i patrons amb l‟objectiu de definir un sistema amb el suficient detall per permetre en una etapa posterior la seva implementació. Per tant haurem de definir l‟estructura interna i externa que el nostre sistema haurà de tenir. 4.1 Disseny de l’arquitectura La primera decisió que hem prendre és quin patró arquitectònic s‟ajusta més a les nostres necessitats i ens facilitarà el desenvolupament. El patró escollit determinarà l‟estructura interna i les característiques finals que tindrà el nostre sistema un cop implementat. Abans de començar a definir l‟arquitectura, és necessari identificar les propietats que volem que el nostre sistema tingui un cop implementat, ja que la identificació d‟aquestes propietats condicionarà l‟elecció del patró arquitectònic. Les propietats que volem que el nostre sistema tingui són les següents: -Canviabilitat: a) Extensibilitat: Faciliti la tasca d‟ampliació de les funcionalitats del sistema. b) Mantenibilitat: Faciliti la detecció i reparació d‟errors -Provable: Que ens faciliti les proves del sistema -Fiable: Tracti correctament comportaments erronis quan es produeixin. Capítol 4 Disseny 46 -Reutilitzable: Ser capaç de poder produir software que pugui ser reutilitzat en futur. Altres característiques com la portabilitat no s‟han tingut tant en compte, ja que treballarem amb un hardware tancat que utilitzarà unes biblioteques específiques per ell, amb la qual cosa podem determinar amb força exactitud que el disseny d‟una part del nostre sistema estarà molt lligat amb el hardware que utilitzarem i ens serà molt difícil, per no dir impossible, portar aquesta part del sistema a altres plataformes sense utilitzar emuladors. En els següents apartats descriurem el diferents patrons de disseny que hem utilitzat finalment en el nostre sistema. 4.1.1 Arquitectura en capes El patró de disseny en capes té com a objectiu separar els components del nostre sistema en diferents capes, aconseguint així les propietats de canviabilitat que busquem. Un inconvenient que comporta aquest patró és que n‟augmenta la ineficiència, ja que la comunicació entre els elements del nostre sistema és durà a terme entre les capes. En canvi un avantatge d‟aquesta arquitectura és que produeix codi modular que ens permet modificar alguna de les capes sense haver de tocar-ne cap altra. L‟ arquitectura que utilitzarem es presenta en una estructura amb 3 capes com la mostrada a la figura 4.1. Capa de Presentació Capa de Dades Capa de Domini Usuari Figura 4. 1 Arquitectura en tres capes On cada una de les capes s‟encarrega de:  Capa de Presentació: És l‟encarregada de presentar el nostre sistema a l‟usuari. S‟encarrega d‟obtenir les peticions que l‟usuari realitza i de comunicar-les a la capa de domini. De la pròpia capa de domini n‟obté les modificacions que s‟han produït i les comunica a l‟usuari. Capítol 4 Disseny 47  Capa de Domini: S‟encarrega de representar totes les funcionalitats i encapsular les dades del nostre sistema.  Capa de Dades: S‟encarrega d‟emmagatzemar les dades del nostre sistema. 4.1.2 Patró MVC El Model-View-Controller (Model-Vista-Controlador o MVC) és un patró arquitectònic que té com a objectiu principal separar la lògica de negoci de la lògica de presentació (interfície gràfica) de la nostra aplicació. El patró s‟estructura en tres grans components:  Model: Encapsularà les dades del sistema i les seves funcionalitats. En un arquitectura en capes com la que volem utilitzar podem dir que correspon a la capa de Domini.  Controlador: Definirà el comportament del sistema.  Vista: És la interfície gràfica del sistema i l‟encarregada de notificar les peticions que l‟usuari realitza. Dintre del propi patró MVC existeixen diverses variants, adoptant en cada una d‟elles diferents interaccions entre els components que el formen. Una de les variants és la descrita en la figura 4.2, on el controlador és l‟encarregat de realitzar crides al model (ja siguin consultores o modificadores), i al mateix temps l‟encarregat de modificar la vista segons sigui pertinent. Model -Encapsula les dades del sistema -Encapsula les funcionalitats del sistema Controlador -Defineix el comportament del sistema -Modifica el model -Actualitza la vista VISTA -Mostra la interficie gràfica del sistema -Envia la interecció de l’usuari al controlador Figura 4. 2 Patró de disseny MVC En el nostre sistema s‟aplicarà a la capa de presentació, on farem una distinció clara entre les classes de la vista i les del controlador. Capítol 4 Disseny 54 Dels dos diagrames en podem extreure que efectivament trobem un comportament comú en tots tres jocs i que caldrà perfilar el comportament específic per cada un d‟ells. Per exemple, en el diagrama de la figura 4.8, veiem que pel joc Sator tindrem un comportament específic en la fase d‟inicialització, ja que haurem de configurar una posició inicial per totes les fitxes, cosa que també pot succeir en el joc Tenet, en canvi en el joc Arepo tindrem un procés que consistirà en generar de forma aleatòria quin és el primer jugador a tirar. Aquest comportament específic el dissenyarem utilitzant un sistema jeràrquic de classes on en les subclasses s‟especificarà aquest comportament per cada un dels jocs. Basant-nos en aquesta metodologia obtenim el següent sistema de classes pels controladors dels diferents jocs: -estat : s8 CInterficie -alternar : bool -colorFitxes CInterficieInicialitzacio -regles : Regles -dis : Disp CInterficieArepo CInterficieSator -iniciarConfiguracio : bool CInterficieTenet CInterficieSatorSolo CInterficieSatorMulti CInterficieSatorWifi CInterficieTenetSolo CInterficieTenetMulti CInterficieTenetWifi CInterficieArepoSolo CInterficieArepoMulti -playerActual : s8 -disposicioActual : Disp CInterficieArepoWifi Tauler 1 1 ControladorJoc Utils So 1 1 1 1 1 1 Figura 4. 9 Diagrama de classes dels controladors. On cada nivell de l‟estructura jeràrquica de les classes CInterficie conté tot el comportament comú de les seves subclasses. Per mostrar la metodologia seguida mostrarem els mètodes de la classe CInterficie, separats entre els mètodes comuns (veure figura 4.10) i els mètodes virtuals (veure figura 4.11) +iniciarPartida() +tirarPlayer(entrada tipus : Tipus) +carregarFitxes(entrada tipus : Tipus) CInterficie Figura 4. 10 CInterficie mètodes comuns Capítol 4 Disseny 55 +inicialitzacionsEstatITauler() +inicialitzacionsP1() +inicialitzacionsP2() +tirarContrincant(entrada tipus : Tipus) +mostrarNoPotMoure() +menuDePausa() : FiDePartida +seguentPlayer() +animacioMarcarPlayerActual(entrada idPlayer : s8) +comprovacioTipusAux(entrada spr : FitxaTipus) +actualitzarInterficie(entrada lm : llistaMatar) +tractamentDadesAux(entrada fdp : FitxaInfo) +tractamentFinalitzacioAux(entrada fi : FiDePartida) +altresComprovacionsPad(entrada tipus : Tipus, entrada id : s8) +partidaAcabada(salida jugador : s8) : bool +mostrarResutat(entrada jugador) : FiDePartida +tractamentEstatAlReiniciar() +obtenirNomPlayer(entrada jugador : s8, entrada y salida nom[] : char) CInterficie Figura 4. 11 CInterficie mètodes virtuals Una de les raons d‟introduir un tercer nivell a la jerarquia de classes, es basa en què ens facilitarà introduir el comportament específic per cada un dels tres modes de joc: individual, multi jugador i comunicació sense fils. Aquest comportament específic és: -Redefinició de com actua l‟adversari tal i com queda reflectit en el diagrama de la figura 4.12. -Redefinir com es presenta el resultat final d‟una partida, ja que mostrarem diferents vistes (gràfics i música) segons el mode de joc i el tipus de joc en el que estiguem jugant. InterficieSatorSolo tirarContrincant() IA() InterficieSatorMulti tirarContrincant() tirarJugador() InterficieSatorWifi tirarContrincant() esperarMovimentWifi() Figura 4. 12 Comportament específic 4.2.1.2 Menú A l‟hora de dissenyar el nostre sistema hem cregut convenient separar totalment la interfície gràfica utilitzada pels tres joc, amb el sistema de menús que utilitzarem per Capítol 4 Disseny 56 accedir-hi. S‟ha pres aquesta decisió per així diferenciar les classes pel menú amb les classes dissenyades pels diferents jocs. El menú que utilitzarem en el nostre joc consistirà en una sèrie de pantalles relacionades entre elles com hem reflectit en l‟esquema de navegació del capítol 3. Per tant caldrà dissenyar una estructura que ens faciliti dissenyar aquestes pantalles i que n‟automatitzi alguns passos. La figura 4.13 mostra el diagrama UML de les classes participants que hem dissenyat per implementar el menú. -tipus : Tipus -numSprites : byte Menu ControladorSprites ControladorBackGrounds ControladorText So -numSprites : int -sprites[128] : TipusSprite -numPaletta : int InfoSprite +tipus : Tipus +mode : ModeSprite «struct» TipusSprite +DUAL +SCREEN0 +SCREEN1 «enumeration» ModeSprite +SELECTMODOSOLO +SELECTMODOMULTI +SELECTMODOCREDITS +LOGOSATOR +LOGOAREPO +LOGOTENET +GOBUTTON +.... «enumeration» Tipus 1 1 11 1 1 1 1 1 1 CInterficie 1 1 1 1 Figura 4. 13 Diagrama UML menú. La finalitat d‟aquest disseny es basa en que dissenyarem totes les pantalles del nostre menú en la classe Menu, fent ús dels diferents controlador de gràfics: ControladorSprites, ControladorBackGrounds i ControladorText, per gestionar i facilitar la creació de les diferents pantalles. A més a més serà necessari mantenir un estat general del sistema on quedi reflectit les opcions de partida escollides, la pantalla actual i la informació de l‟usuari; per aquesta tasca utilitzarem una classe de Domini anomenada Game que serà explicada posteriorment. A continuació passarem a explicar les funcionalitats que té cada una de les classes utilitzades en el disseny del menú excepte la classe CInterficie que ja ha estat explicada (veure figura 4.14 on queden reflectits tots els mètodes dels que disposem):  Menu: s‟utilitzarà per definir totes les pantalles del nostre joc mitjançant la utilització dels diferents controladors de gràfics. Capítol 4 Disseny 57  ControladorSprite: S‟encarrega de dibuixar tots els sprites que han d‟aparèixer per pantalla i animar-los quan sigui necessari. També s‟encarregarà de controlar la interacció d‟aquests sprites amb l‟usuari. Necessitarà tenir associat la classe InforSprite per gestionar-ne els identificadors així com també la classe So.  ControladorBackGround: S‟encarrega de mostrar el background correcte per cada una de les pantalles seleccionades.  ControladorText: S‟encarrega de mostrar tot el text fixa del nostre joc, això inclou les normes del joc i els diferents texts explicatius per cada una de les pantalles. D‟aquesta manera aconseguim concentrar en una classe la major part del text del menú.  So: S‟encarregarà de fer sonar els efectes sonors i melodies del nostre joc. +menuPrincipal() +menuSplash() +menuSaveData() +menuNoFat() +menuPartides() +menuMultiplayer() +...() -tipus : Tipus -numSprites : byte Menu +dibuixarSprites(entrada sprites[] : Sprite, entrada numElements : s8) +moureSprites(entrada sprites[] : Sprite, entrada numElements : s8) +borrarSprites() +dibuixarAnimacions(entrada sprites[] : Sprite, entrada numElements : s8) +borrarAnimacions(entrada sprites[] : Sprite, entrada numElements : s8) +esperarIntereccioUsuari() : Tipus +consultarIntereccioUsuari() : Tipus +nouSoSprite(entrada tipus : Tipus) +marcarSlot(entrada tipus : Tipus) -spriteADibuixar(entrada tipus : Tipus, entrada pos : posicio) -animarSprite(entrada idSprite : s8) ControladorSprites +dibuixarBackGround(entrada screen : s8, entrada profunditat : s8, entrada tipus : TipusFons) +dibuixarBackGround16Bits(entrada screen : s8, entrada tipus : TipusFons) +dibuixarTransicio(entrada screen : s8, entrada color : Color, entrada trans : Trasicio) +esborrarBackGround(entrada screen : s8, entrada profunditat : s8) +configurarMode16Bits(entrada screen : s8) +desconfigurarMode16Bits(entrada screen : s8) ControladorBackGrounds +printarText(entrada screen : FaseJoc) +printarRegles(entrada joc : Joc, entrada pagina : s8) +printarOpcionsDePartidaSator(entrada ....) +printarOpcionsDePartidaArepo(entrada ...) +printarOpcionsDePartidaTenet(entrada ...) +mostrarDisposicioJugadorsMultiPlayer(entrada ...) ControladorText +nouSoOST(entrada so : TipusSo) +nouSoEfecte(entrada so : TipusSo) So +getNumSpriteMax() +getIdSprite(entrada tipus : Tipus, entrada mode : ModeSprite) +getId(entrada tipus : Tipus, entrada num : s8) +getIdPaletta() +borraSprites() InfoSprite +tipus : Tipus +mode : ModeSprite «struct» TipusSprite +DUAL +SCREEN0 +SCREEN1 «enumeration» ModeSprite +SELECTMODOSOLO +SELECTMODOMULTI +SELECTMODOCREDITS +FITXAP1 +FITXAP2 +FITXAP3 +FITXAP4 +.... «enumeration» Tipus 1 1 1 1 1 1 1 1 +tipus : Tipus +pos : posicio «struct» Sprite 1 1 +FONSNORMAL +FONSNORMALV2 +FONSFIB +... «enumeration» TipusFons +PANTALLA_PRINCIPAL +PANTALLA_PLAYERS +PANTALLA_SAVE_DATA +... «enumeration» FaseJoc +OKSOUND +BACKSOUND +MENUSO +... «enumeration» TipusSo Figura 4. 14 Diagrama UML menú Capítol 4 Disseny 58 Per explicar amb més claredat la metodologia seguida per definir les diferents pantalles farem ús d‟un diagrama de seqüència que mostrarà les classes participants en la creació de les diferents pantalles. Primer ens centrarem en el tipus de pantalles que només necessiten saber quin element s‟ha premut per automàticament passar a la següent pantalla (veure Figura 4.15). Menu pintarPantalla(Sprites[], int) borrarPantalla() ControladorSprites InfoSprite esperarInteraccioUsuari() esperarIntereccio() getNumSpritesMax() getTipus() Tipus animarSprite() Figura 4. 15 Diagrama de seqüència Pantalla bàsica On la funció pintarPantalla(..) i borrarPantalla() queden descrites en els diagrames de les figures 16 i 17 respectivament. Menu ControladorSprites ControladorText ControladorBackGrounds dibuixarSprites(Sprite[], int) printarText(idScreen) dibuixarTransicio(screen, color, DESAPLICAR) pintarPantalla(Sprites[], numSprites) InfoSprite getIdSprite(Tips, modeScreen) getIdPaletta() PA_CreateSprite(....) per tots els sprites rebuts Figura 4. 16 Diagrama de seqüència funció pintarPantalla() Capítol 4 Disseny 59 Menu borrarPantalla() ControladorBackGrounds ControladorSprites dibuixarTransicio(screen, Color, APLICAR) borrarSprites() InfoSprite borrarSprites() actualitzarPantallaActual(Tipus) actualitzarBackGround() Figura 4. 17 Diagrama de seqüència de la funció borrarPantalla() La funció pintarPantalla(..) dibuixa els sprites a les posicions donades, escriu el text corresponent a la pantalla actual i finalment desenfosqueix la pantalla perquè puguem veure‟n el contingut. La funció borrarPantalla té el comportament oposat; enfosquir la pantalla, esborrar-ne tots els elements gràfics i actualitzar convenientment quina és la propera pantalla a pintar. Per altra banda també tenim les pantalles que requereixen que un certs sprites siguin premuts per canviar de pantalla. És el cas de les pantalles on s‟escullen les opcions de partida d‟un dels jocs, fins que no s‟ha premut el botó endavant o endarrere no s‟actualitza la pantalla. El diagrama de la figura 4.18 mostra el procediment seguit. mentre !botóEndevant o !botóEnrere Menu pintarPantalla(Sprites[], int) borrarPantalla() ControladorSprites InfoSprite consultarIntereccioUsuari() consultarSpriteApretat() getNumSpritesMax() getTipus() Tipus animarSprite() Si apretatSprites comprovem el tipus premut i actualitzem informació Figura 4. 18 Diagrama de seqüència pantalla complexa Capítol 4 Disseny 60 4.2.1.3 Disseny Gràfic Dintre del disseny de l‟estructura de la capa de presentació també hem de dissenyar-ne l‟aparença visual que aquesta tindrà. Hem de dir que durant la realització del projecte el disseny de l‟apartat gràfic no s‟ha cenyit exclusivament a aquesta etapa, ja que durant el transcurs del projecte s‟han anat introduint variacions en alguns elements gràfics, com per exemple les fitxes dels diferents jocs. L‟estructura interna en cap caps a sofert modificacions, simplement les imatges utilitzades pels diferents gràfics han anat variant per aportar un aspecte visual més agradable. A continuació mostrarem alguns elements gràfics que hem introduït en el nostre joc per tal de millorar-ne l‟aparença visual: Fitxes i cartes: Botons: Taulers: Altres elements: Capítol 4 Disseny 61 Pantalla principal (logotip): Pantalles superiors menú: Menú de pausa i de resultat Capítol 4 Disseny 62 4.2.2 Capa de Domini Un cop dissenyada la capa de presentació es mostrarà el disseny de la capa de domini. El disseny es dividirà en diferents diagrames UML per facilitar-ne l‟explicació. Per començar s‟analitzarà les entitats que hem utilitzat per representar l‟estat del diferents jocs (tauler, fitxes, cartes, les seves regles i moviments vàlids), juntament amb les classes que representen la intel·ligència artificial. Em optat per mostrar-les juntes ja que existeix una forta relació entre elles. -jugador : s8 -board[] : s8 -numFitxes : s8 -numCeles : s8 Estat EstatInicialitzacio -mortesP1 : s8 -mortesP2 : s8 EstatArepo -mortesBlanquesP1 : s8 -mortesBlanquesP2 : s8 -mortesVermellesP1 : s8 -mortesVermellesP2 : s8 EstatSator -idCartaP1 : s8 -idCartaP2 : s8 -mortesP1 : s8 -mortesP2 : s8 -mortesCartesP1 : s8 -mortesCartesP2 : s8 EstatTenet -idFitxa : s8 -posicioF : posicio -morta : bool Fitxa -color : ColorFitxa -visible : bool FitxaSator -numCartes : s8 -tipus : TipusTenet FitxaTenet FitxaArepo -idCarta : s8 -morta : bool -tipusCarta : TipusTenet -tipusMoviment : TipusTenet Carta 1 1..5 Utils 1 1 110 1 10 -profunditat : int -maxValor : int -minValor : int -tipusInicial : Tipus IA IASator IATenet IAArepo 1...* 11 1...* 1...* 1 +FITXAP1 +FITXAP2 +FITXAP3 +FITXAP4 «enumeration» Tipus +tipus : Tipus +id : s8 +pos : posicio «struct» FitxaInfo +tipus : Tipus +id : s8 +idCarta : s8 +pos : s16 «struct»FitxaInfoCarta +X +Y «struct»posicio +BLANCA +VERMELL +NOCOLOR «enumeration» ColorFitxa +REI +CAVALL +ALFIL +TORRE +DAMA «enumeration» TipusTenet Figura 4. 19 Model conceptual del domini Si es compara el model de la figura 4.19 amb el model conceptual del capítol 3 veiem que s‟han produït alguns canvis. De la mateixa manera que s‟ha procedit en el disseny de la capa de presentació s‟ha introduït una nova classe anomenada EstatInicialització per agrupar les funcionalitats comunes corresponents a la fase d‟inicialització de les posicions de les fitxes dels jocs Sator i Tenet. Cada un del les classes Estat conté doncs, totes les funcions necessàries per modificar i consultar els diferents elements que componen l‟estat del joc. Deixarem al marge l‟explicació dels algoritmes dissenyats en les classes de la intel·ligència artificial Capítol 4 Disseny 63 ja que seran explicades amb detall en el capítol 6. A continuació descriurem el contingut de cada una de les classes que representen l‟estat dels diferents jocs.  Classe Estat: Ens servirà per agrupar els atributs comuns de tots tres jocs. Tots els jocs es basen en un tauler que serà representat com un vector, i una sèrie de valors que ens indicaran el nombre de caselles, el nombre de fitxes per jugador i quin és el jugador que li toca tirar. Com tots tres jocs tenen un mínim de deu fitxes també ens serà possible representar-les en aquesta classe. Per altra banda també podrem agrupar les funcionalitats per saber si hi ha una fitxa en una posició donada (veure funcionalitats comunes a la figura 4.20) +getNumFitxes() : s8 +getNumCeles() : s8 +getJugador() : s8 +setJugador(entrada jugador : s8) +hihaFitxaP1(entrada pos : posicio) : bool +hihaFitxaP2(entrada pos : posicio) : bool +hihaFitxa(entrada pos : posicio) : bool +hihaFitxa(entrada tipus : TipusD, entrada pos : posicio) : bool +posicioValida(entrada posNova : posicio, entrada lp : llistaPosicions) : bool -jugador : s8 -board[] : s8 -numFitxes : s8 -numCeles : s8 Estat Figura 4. 20 Classe Estat  Classe EstatInicialitzacio: Engloba les funcionalitats que permeten realitzar una inicialització de les posicions de les fitxes en el tauler, és a dir, conté aquells mètodes que utilitzarem en la fase de configuració de les posicions inicials de les fitxes en els jocs Sator i Tenet (veure figura 4.21). +getFitxaMorta(entrada tipus : TipusD, entrada numFitxa : s8) +comprovarInici(entrada tipus : TipusD) : bool +actualitzarEstatInicial(entrada tipus : TipusD, entrada numFitxa : s8, entrada posNova : posicio) +desactualitzarEstatInicial(entrada tipus : TipusD, entrada numFitxa : s8) EstatInicialitzacio Figura 4. 21 Classe EstatInicialitzacio  Classes específiques per cada un dels jocs: Contenen totes les funcionalitats característiques de cada un dels jocs. En elles trobarem els mètodes que ens indiquin quins moviments són vàlids, quan una partida ha finalitzat i la funció heurística que utilitzarem en les intel·ligències artificials, juntament amb els mètodes per la consulta i modificació de certs elements específics per cada un dels jocs. Les diferencies entre els diferents estats es basen en: Tenet: necessita un conjunt de mètodes per poder consultar l‟estat de les cartes associades a cada una de les fitxes; el nombre de cartes no 70 Capítol 5 Implementació 71 Capítol 5 Implementació Un cop finalitzat el disseny del nostre sistema cal passar a la fase d‟implementació. En aquest capítol exposarem algunes decisions que hem hagut de prendre a l‟hora d‟implementar algunes funcionalitats del nostre sistema. Existeix una amplia documentació a la xarxa [DOC] que explica amb força detall totes les funcionalitats i capacitats que ofereixen les biblioteques utilitzades. Com aquest document no pretén ser un manual per explicar com utilitzar-les, ens centrarem exclusivament amb les decisions relacionades amb la utilització d‟unes o altres funcionalitats.. 5.1 Llenguatge de programació La biblioteca PAlib i totes les altres biblioteques que utilitzarem han estat implementades en C, per tant les opcions més eficaces que tenim són el C i ell C++. Donada l‟envergadura del projecte i la necessitat que tenim, com ha quedat pales en l‟etapa de disseny, d‟utilitzar les característiques que ens aporten els llenguatges orientats a objectes, hem decidit implementar el nostre joc utilitzant el llenguatge de programació C++. 5.2 Metodologia biblioteca PAlib Un dels primers passos que calia seguir un cop instal·lat tot l‟entorn de treball era començar-se a familiaritzar amb quina era la metodologia que seguia aquesta biblioteca i com havíem de treballar amb ella. Els primers passos van consistir en seguir alguns manuals que es poden trobar a la xarxa que mostren amb relativa facilitat com programar les diferents funcionalitats de la consola fent ús d‟aquestes biblioteques. En aquests manuals pots trobar com mostrar sprites per pantalla, com carregar backgrounds12, com pintar text, com controlar la interacció de l‟usuari a través dels 12 Paraula anglesa per referir-se als fons de pantalla Capítol 5 Implementació 72 botons digitals o de la pròpia pantalla tàctil, com fer sonar música i molts altres exemples que ens permeten comprovar les funcionalitats que ens dóna la biblioteca. Un cop havíem experimentat amb diversos exemples calia començar a plantejar una primera idea de com havíem de dissenyar la nostra interfície gràfica. Els punts bàsics els passo a comentar a continuació: Peticions de l’usuari Una particularitat que té el desenvolupament per la consola Nintendo DS amb les biblioteques PAlib, és que només podem capturar la interacció de l‟usuari amb la pròpia consola, ja sigui a través de la pantalla tàctil o dels botons digitals, mitjançant un algoritme d‟enquesta13. No tenim la possibilitat de definir interrupcions o funcions que s‟executin automàticament quan es produeix una interacció per part de l‟usuari, com podria ser prémer el botó de pausa. D‟aquí s‟extreu que tot el control de la interacció de l‟usuari amb la consola s‟haurà de controlar efectivament mitjançant la utilització d‟un algoritme d‟enquesta, en el qual es comprovarà de forma ininterrompuda l‟estat dels diferents elements d‟interacció. Això comporta uns inconvenients clars, ja que una interacció per part de l‟usuari només podrà ser capturada si en aquell precís instant s‟està comprovant l‟estat de l‟element en qüestió. Podríem pensar que no es tracta d‟un problema seriós ja que les funcionalitats del nostre sistema no seran gaire complexes i s‟executaran de forma ràpida. Però hem de tenir en compte que poden existir algunes funcionalitats costoses, com els càlculs que efectuarem relacionats amb la intel·ligència artificial, i l‟única solució que ens ofereixen les biblioteques per consultar la interacció de l‟usuari durant aquests càlculs seria introduir codi específic PAlib dintre de les classes participants d‟aquest càlculs, cosa que òbviament no volem fer. La decisió que finalment es va prendre és no permetre la interacció de l‟usuari amb la consola mentre s‟estan realitzant càlculs costosos com els relacionats amb la intel·ligència artificial. Una conseqüència clara d‟aquesta decisió és que no podrem accedir al menú de pausa mentre el sistema està calculant el moviment per la intel·ligència artificial. Gestió de gràfics i música La biblioteca no ofereix estructures complexes pel tractament de sprites. Només ens ofereixen les funcionalitats bàsiques com pintar, esborrar, moure i animar, deixant la gestió d‟identificador a càrrec del programador, cosa que caldrà tenir-la en compte a l‟hora de dissenyar el sistema. 13 Entenem per algoritme d‟enquesta, un algoritme que consisteix en un bucle que no finalitza fins que l‟estat d‟alguna de les variables que està consultant ininterrompudament varia. Capítol 5 Implementació 73 De la mateixa manera ens trobarem en una situació similar amb la gestió dels backgrounds o quan volem mostrar text per pantalla, i també necessitarem alguna estructura que ens faciliti l‟inici d‟efectes sonors o d‟alguna melodia. Característiques Gràfiques Un altre aspecte que havíem de tenir clar a l‟hora de programar per la consola, era quin tipus de gràfics podíem mostrar per pantalla, és a dir, quines característiques devien complir i quines limitacions teníem a l‟hora de crear-los. A continuació passo a comentar aquells que han tingut més pes:  Tenim la capacitat de mostrar per pantalla backgrouds de 256 colors o de 16 bits de color. Si utilitzem backgrounds de 256 colors, podem arribar a mostrar-ne simultàniament fins a quatre, en canvi si volem utilitzar només imatges de 16 bits estem limitats a només poder-ne mostrar un. Si optem per utilitzar backgrounds de 16 bits hem d‟anar en compte ja que ocupen molts recursos, i podem trobar-nos amb incompatibilitats si els volem barrejar amb altres elements gràfics. La grandària dels backgrounds pot ser de 256 x192 píxels en cada pantalla.  Capacitat per mostrar fins a 128 sprites simultàniament per pantalla. Es poden definir sprites amb unes dimensions com les de la següent taula Píxels 8 16 32 64 8 8x8 16x8 32x8 16 8x16 16x16 32x16 32 8x32 16x32 32x32 64x32 64 32x64 64x64 Com és obvi com més grans són els sprites carregats, més memòria ocupen, i per tant el límit de 128 sprites es veu reduït. En aquest aspecte vam estar de sort ja que en el joc Tenet vam arribar quasi bé al límit dels que disposàvem.  Disposem d‟un màxim 16 palettes de 256 colors, per utilitzar en la representació dels diferents sprites.  Tenim la capacitat per reproduir arxius de música en format mp3, wav, raw14 i mod.  Tenim una limitació de 4MB pel nostre joc. El fitxer que generem quan compilem el nostre programa, és executat per la consola carregant-lo íntegrament a la memòria ram, i només disposa de 4MB de ram. 14 Format d‟àudio que requereix molt poc espai en disc i que s‟utilitza pels efectes sonors Capítol 5 Implementació 74  Tenim la capacitat per definir tipus de lletra personalitzats. La consola disposa de quatre tipus de lletres de 16 colors (una mateixa font però diferents grandàries), i en podem definir fins a cinc tipus addicionals. 5.3 Decisions d’implementació En aquest apartat definirem algunes decisions que s‟han pres durant l‟etapa d‟implementació i que estan relacionades amb les diferents funcionalitats que ens ofereix la biblioteca PAlib. Gràfics i so En l‟apartat anterior hem comentat que disposem exclusivament de 4MB pel nostre joc, ja que aquest serà carregat directament a la memòria ram de la consola. Aquí havíem de prendre una decisió important ja que tot i que una limitació de 4MB no hauria de resultar problemàtic per un programa per si sòl, es pot tornar un problema si també hi hem d‟incorporar tots els elements gràfics i sonors de la nostre aplicació. Les pròpies biblioteques ens ofereixen dues possibilitats: Incloure els gràfics i el so dintre del propi arxiu que es generarà en la compilació. Llegir-los de forma externa. Com l‟espai en memòria que utilitzarem per la representació del model (Estat, fitxes, Tauler, etc) un cop executat un joc és relativament petit, i com bona part dels gràfics i fons de pantalla ocupen pocs Kbytes, es va decidir finalment optar per incorporar dintre del mateix fitxer tots els gràfics i música. D‟aquesta manera també aconseguirem una major facilitat en distribuir el nostre joc, ja que amb enviar un únic arxiu en tindrem prou. Funcionalitats no compatibles amb emuladors Els emuladors disponibles per la consola Nintendo DS són capaços d‟emular totes les capacitats tècniques de la consola, amb l‟excepció de l‟escriptura en fitxers externs i la comunicació sense fils. Com el nostre joc s‟havia de poder executar tant en la pròpia consola Nintendo DS com en algun emulador, va ser necessari introduir alguns elements de comprovació que permetessin assegurar-ne el correcte funcionament (introduint alguns pantalles específiques com l‟avís d‟impossibilitat per guardar partides), tot i que com hem comentat en el capítol 1 assegurem el bon funcionament exclusivament per l‟emulador utilitzat en el desenvolupament dels jocs. Capítol 5 Implementació 75 Tipus de fitxers d’àudio La biblioteca PAlib ens dóna la possibilitat d‟utilitzar diferents formats d‟àudio pel nostre joc; mp3, wav, raw o mod. Un cop decidit que volíem incorporar tots els elements gràfics i sonors dintre del propi fitxer compilat, era necessari escollir aquells formats que donessin uns resultats excel·lents i al mateix temps ocupessin poc espai a memòria. De tot plegat es va decidir utilitzar els següents formats: raw: el format estàndard que s‟utilitza pels efectes sonors. És el cas dels diferents sons que es sentiran quan s‟ha premut un botó o quan es toca una de les fitxes en els diferents jocs. mod: Conté les diferents melodies que utilitzarem en el nostre joc. S‟ha optat per utilitzar aquest format pel tipus de so electrònic que acostumen a tenir i pel poc espai que ocupen si el comparem amb la qualitat que ofereixen. Aquest format d‟àudio, de la mateixa manera que succeeix amb el format MIDI, no emmagatzemen el propi so, sinó que emmagatzema una partitura que serà interpretada al reproduir-se. Els diferents fitxers mod que hem utilitzat en el nostre joc han estat trobats a [MOD]. Opcions de compilació En les últimes actualitzacions de la biblioteca PAlib s‟han introduït diferents opcions de compilació que ens permeten utilitzar unes funcionalitats o unes altres conjuntament. Com havíem decidit implementar una comunicació sense fils i a més a més hem decidit que volem utilitzar fitxer d‟àudio de tipus mod, calia seleccionar l‟opció de compilació que permetés utilitzar les dues funcionalitats al mateix temps. Aquesta opció de compilació correspon a: ARM7_SELECTED = ARM7_MOD_LIBLOBBY. Variables A l‟hora d‟implementar el nostre sistema hem utilitzat els següents tipus de dades bàsics per la representació de valors numèrics: Tipus Bits Rang s8 8 bits -128 -> 127 s16 16 bits -32 768 -> 32 767 s32 32 bits -2 147 483 648 -> 2 147 483 647 On utilitzem un o altre tipus de dades, segons el tipus d‟informació que volem representar. Per exemple, si volem representar el nombre de caselles utilitzarem el tipus s8, en canvi per representar la posició en píxels on s‟ha de situar un element, es fa necessari utilitzar un s16. Capítol 5 Implementació 76 Variables globals Hem decidit implementar la classe Game, definida en l‟etapa de disseny, com a variable global en el nostre sistema. S‟ha fet d‟aquesta manera ja que les funcionalitats que ofereix i l‟estat del sistema que representa, haurà de mantenir-se durant tot el temps d‟execució del nostre joc. 5.4 Estructura del nostre sistema Quan ens disposem a implementar un projecte software cal tenir ben organitzat tots els arxius que utilitzarem, ja que d‟aquesta manera ens serà més fàcil localitzar-los dintre del sistema. A continuació explicarem l‟estructura de fitxers que hem utilitzat en el nostre projecte: /ProjecteNDS/ Directori principal del nostre projecte. Conté el MakeFile per compilar-lo. /ProjecteNDS/data Directori que conté tots els arxius de música del nostre joc /ProjecteNDS/source Directori on inclourem tots els arxius i directoris amb el codi font del projecte, i els gràfics utilitzats. Hi podem trobar: /source/gfx Directori amb tots els gràfics utilitzats. /source/Interficie Directori amb el codi font corresponent a la capa de presentació. Tenim subdirectoris per diferenciar el Menu, el Controlador i la Vista. /source/Variables Directori que conté el codi font corresponent als diferents structs i enumerations definits en el nostre sistema /source/DominiDades Directori amb el codi font corresponent a la capa de domini i de dades. Tenim dos subdirectoris on s‟inclouen les classes corresponents al controlador de la Capítol 5 Implementació 77 capa de domini, i les classes participants de l‟estat dels diferents jocs juntament amb les de la intel·ligència artificial. 5.5 Estil de programació La llegibilitat és un dels criteris que es té en compte a l‟hora d‟avaluar un programa, ja que un codi llegible podré ser molt més modificable per un programador que no hagi participat durant el desenvolupament del projecte. Els principals elements d‟estil són: Declaració de variables: Seran declarades sempre al principi d‟un bloc de codi El nom sempre començarà en minúscules. Si el nom de la variable té un nom compost, les noves paraules seran començades amb majúscula. Utilització d’enumeracions: Utilitzarem enumerations sempre que sigui possible per representar els diferents valors que pot prendre una variable. Utilització de structs: Utilitzarem structs per englobar en un nou tipus de dada, dades més simples. Inici i tancament de bloc: Les claus utilitzades per la delimitació d‟un bloc seran obertes en la mateixa línia de la declaració del bloc i tancades al final d‟aquest com es mostra en el següent exemple: if (condició) { } else { } Declaració de mètodes: El nom sempre començarà en minúscules. Si el nom del mètode té un nom compost, les noves paraules seran començades amb majúscula. Els atributs dels mètodes sempre estaran en minúscules. 78 Capítol 6 Intel·ligència Artificial 79 Capítol 6 Intel·ligència Artificial Amb el sorgiment de les primeres intel·ligències artificials als anys 1950, el considerat pare de la ciència de la computació Alan Turing15 va proposar l‟anomenada prova de Turing per corroborar l‟existència d‟intel·ligència en una màquina. En comptes de suggerir una sèrie de qualitats que una màquina devia complir per ser considerada intel·ligent, va desenvolupar una prova en què una màquina seria considerada intel·ligent si un ésser humà era incapaç de diferenciar si s‟estava comunicant amb ella o amb una persona. Això òbviament comportava una sèrie de capacitats que devia tenir la màquina tals com el processament del llenguatge natural, la representació del coneixement, i ser capaç d‟aprendre i utilitzar el raonament automàtic per respondre d‟una manera coherent a les preguntes formulades. En l‟actualitat la intel·ligència artificial conté diverses ramificacions; des d‟àrees de propòsit general, com l‟aprenentatge i la percepció de l‟entorn, a altres més específiques com la teoria de jocs, la demostració de teoremes matemàtics, l‟escriptura o el diagnòstic de malalties. Si ens centrem en aquestes últimes àrees, podríem suggerir una altra definició per la intel·ligència artificial; una màquina és intel·ligent si és capaç d‟automatitzar computacionalment tasques intel·lectuals i donar respostes i solucions coherents a preguntes formulades per nosaltres. En el projecte que ens inclou utilitzarem l‟anomenada teoria de jocs per donar una resposta clara a la següent pregunta: “quin és el millor moviment que puc fer per aconseguir guanyar la partida actual?”. 6.1 Teoria de jocs Els jocs han estat estudiats al llarg dels últims 60 anys per crear noves i millor tècniques que permetessin crear programes que juguessin cada cop millor en els diferents jocs existents. Aquesta evolució pot ser explicada pels nous algoritmes i els 15 Alan Mathison Turing (1912-1954) matemàtic, informàtic teòric, criptògraf i filòsof, va ser un dels primers en desenvolupar una intel·ligència artificial pels escacs. Capítol 6 Intel·ligència Artificial 86 amb la que s‟interacciona té un punt blanc i en l‟altre que té un punt vermell. Això ho aplicarem en dos casos: a) Quan es mata una fitxa de l‟adversari b) Quan una fitxa de l‟adversari arriba al costat oposat de la seva línea de sortida. La creació de les dos histories la podrem dur a terme amb unes funcions de copia especial que ens permetran assignar a una fitxa donada un color determinat. Un cop generats els dos casos possibles, cal tractar el resultat provinent dels dos subarbres generats. El tractament es basa en calcular-ne la probabilitat associada a cada cas i escollir la que ens és més favorable. Per tal que quedi més clar, mostrarem un exemple del cas a) utilitzant una configuració de fitxes senzilla: On sabem que la probabilitat que la fitxa negra del adversari tingui un punt blanc al seu revers és d‟un 66% , i per tant que sigui vermella és d‟un 33%. A continuació mostrem en una taula quin moviment escolliríem segons el color de la fitxa calculat en cada un dels quatre casos possibles. Cas decidim Matar Cas decidim Avançar Moviment a fer Calculem que és vermella Calculem que és vermella Avancem Calculem que és blanca Calculem que és vermella Matem Calculem que és vermella Calculem que és blanca Matem Calculem que és blanca Calculem que és blanca Matem Que és exactament el patró que seguiríem. Si tenim la certesa que la fitxa és blanca optarem per matar ja que en el pitjor dels casos obtindríem un empat. Però com tenim una petita intuïció que la fitxa podria ser vermella, en algun cas decidiríem avançar. Figura 6. 2 Estats successors Sator Capítol 6 Intel·ligència Artificial 87 6.6.1.2. Inicialització Un altra diferència respecte els altres dos jocs, és que requereix sempre una inicialització prèvia de les posicions de sortida de les fitxes. Tant per la informació que ens va facilitat el creador dels jocs Oriol Comas i Coma, com per la pròpia experiència, em determinat que no existeix una situació inicial més beneficiosa que una altre, ja que depèn molt de les posicions que hagi escollit l‟adversari. Com el color de les fitxes de l‟adversari ens és desconegut s‟ha decidit general les posicions inicials aleatòriament. 6.6.1.3. Heurístic: Per començar es descriurà els diversos càlculs que farem sobre una configuració qualsevol de l‟estat del tauler. Agruparem el diferents càlculs en quatre grans grups; mortalitat, amenaces, bloquejades i camí lliure. Mortalitat Aquí es tindran en compte les fitxes mortes de cada un dels jugadors, donant una puntuació fixa per cada fitxa morta, i sumant-li una quantitat addicional depenen del nombre de fitxes visibles que tinguem. Hem utilitzat la següent taula per assignar els diferents valors: Valor Puntuació Fitxa Morta Blanca 15 Fitxa Morta Vermella 10 Fitxa Morta Adversari 15 Visibles Blanques 5 Visibles Vermelles 8 Plus 2 Visibles Vermelles 20 Plus 3 Visibles Blanques 20 La puntuació donada la he extret de la meva pròpia experiència en el joc, d‟on he pogut deduir que és pitjor que et matin una fitxa blanca que no una de vermella, però en qüestió de visibilitat és exactament el contrari, ja que el coneixement que has matat una fitxa vermella et dóna una informació molt més valuosa. De la mateixa manera si tenim dos fitxes blanques o 3 fitxes vermelles visibles disposem de la informació completa de la partida tenint així un avantatge clar respecte l‟adversari. Amenaces Aquí es tindran en compte totes les possibles amenaces que pugui tenir una fitxa dintre del seu rang de visió. Entenem per rang de visió, la zona continguda per la mateixa columna on es troba la fitxa, i cada una de les columnes adjacents. He dividit les amenaces en quatre nivells, del 1 al 4, on el número del nivell equival a la distància relativa entre una fitxa i la seva amenaça (veure figura 6.3), tenint en compte que només ens quedarem amb l‟amenaça més propera. Capítol 6 Intel·ligència Artificial 88 Figura 6. 3 Nivells d’amenaça en el joc Sator A diferència de l‟apartat anterior només es tindrà en compte les fitxes de la IA per realitzar els càlculs, ja que en el joc Sator les amenaces són recíproques (si tu m‟amenaces jo també t‟estic amenaçant) i per tant només caldrà calcular les amenaces des del punt de vista d‟un dels jugadors, per fer-se una idea global de l‟estat de la partida. A més a més es tindrà en compte que els càlculs que realitzarem estaran calculats des de el punt de vista que el següent torn de tirada correspon a l‟adversari, amb la qual cosa unes amenaces ens seran favorables i unes altres desfavorables. a) Nivell 1 També la podríem anomenar amenaça directa, ja que el jugador pot matar una fitxa del seu adversari amb un únic moviment, per tant l‟usuari que tirar primer té les de guanyar. Ara bé, té les de guanyar sempre que no hi hagi més d‟una amenaça en la pròpia partida, ja que el seu adversari podria contraatacar i matar-li una de les seves fitxes, de manera que quedarien en un hipotètic empat. Per tant es tindrà en compte si el nombre d‟amenaces directes és parell o senar. Hem utilitzat la següent taula per assignar els diferents valors: Valor Puntuació Amenaçada Blanca 15*(numAmanaçades%2) Amenaçada Vermella 5*(numAmanaçades%2) Nº Amenaçades Blanques 5 Nº Amenaçades Vermelles 1 Dobles Amenaces 3 On queden reflectides les següents afirmacions extretes de la pròpia experiència:  Que t‟amenacin una fitxa blanca és negatiu, ja que si te la maten l‟únic que en surt perdent ets tu.  Que t‟amenacin una fitxa vermella, es molt millor que no pas que la fitxa amenaçada sigui blanca, ja que en cas que et matin aquesta fitxa, treus una fitxa de l‟adversari fora del tauler.  S‟ha tingut en compte el nombre d‟amenaces, si són parells tindran poc efecte en el resultat final que si són senars. Però amb l‟afegit que es sumarà una quantitat alternativa per cada fitxa amenaçada i per cada amenaça doble (dues fitxes de l‟adversari amenacen una mateixa fitxa teva). Capítol 6 Intel·ligència Artificial 89 b) Nivell 2 Les amenaces de nivell 2, són aquelles en les que si un jugador fa un moviment endavant immediatament té una amenaça directa. A diferència de les anteriors, l‟usuari que fa el primer moviment quasi bé sempre té les de perdre. Ara bé, hi ha un cas en el qual no és favorable, i és dóna en la disposició de fitxes de la figura 6.4. Figura 6. 4 Amenaça de Nivell2 especial On si la nostra fitxa amenaçada és blanca en sortim perdent però si és vermella continuem tenint avantatge. De tot plegat en traiem la següent taula: Valor Puntuació Amenaçada Blanca 10 Amenaçada Vermella 15 Nº Amenaçades Blanques 5 Nº Amenaçades Vermelles 5 Dobles Amenaces 3 Cas desfavorable -15 On l‟amenaça a una fitxa vermella dóna més puntuació que no pas una de blanca. c) Nivell 3 Aquí ens trobem en què un moviment per part d‟un dels jugadors el situa en una amenaçada de nivell 2. Aquest és un dels casos que quan hi ha moltes fitxes en el tauler és poc indicatiu de la bondat de l‟estat, però quan hi ha poques fitxes és molt indicatiu de si aconseguirem guanyar o no. Valor Puntuació Amenaçada Blanca 15 Amenaçada Vermella 10 Nº Amenaçades Blanques 5 Nº Amenaçades Vermelles 5 Dobles Amenaces 3 De la mateixa manera que succeeix en les amenaces directes, tenir una fitxa blanca amenaçada és molt més dolent que tenir-ne una de vermella. Capítol 6 Intel·ligència Artificial 90 d) Nivell 4 Aquest tipus d‟amenaça quan la partida està poc avançada no és indicativa de la bondat de la solució, però en partides molt avançades, el jugador que tira primer té les de perdre. Els valors per les diferents situacions són els mateixos que en el cas anterior. Bloquejades: Un altre aspecte a tenir en compte son les fitxes bloquejades. Podem tenir dos casos de bloquejos, els directes; quan una fitxa n‟està bloquejant una altra impedint el seu moviment, i els indirectes quan una fitxa estarà bloquejada directament al cap de pocs moviments, veure figura 6.5. A més a més els bloquejos poden ser ocasionats per una fitxa del mateix jugador o per una fitxa de l‟adversari. Figura 6. 5 Fitxes bloquejades Si un mateix jugador s‟autobloqueja una fitxa és una condició negativa, i encara més si la fitxa bloquejada és blanca. En canvi bloquejar una fitxa del rival por arribar a ser favorable. L‟assignació de valors a les diverses situacions és el següents: a) Bloquejada una fitxa del rival Com a priori no es pot saber quin tipus de fitxa hem bloquejat del rival, apliquem el següent raonament; como no podem assegurar al 100% si ens serà favorable o desfavorable el que es tindrà en compte és la posició de la fitxa bloquejada. Si la nostra fitxa està més avançada que la del contrari, en cas d‟un suposat empat, tindríem les de guanyar, i si la distancia relativa entre les dues fitxes és elevada és bastant provable que puguem evitar el futur bloqueig. Utilitzarem la següent taula per assignar una puntuació en cada un dels casos exposats: Valor Puntuació Fitxa Bloquejada Blanaca -((4-(posY2 – posY1))-1)*3 Fitxa Bloquejada Vermella ((4-(posY2 – posY1))-1)*3 Distancia relativa Favorable (posY-1)*3 Distancia relativa Desfavorable -(2-posY)*3 Capítol 6 Intel·ligència Artificial 91 On es penalitza que se‟ns bloquegi una fitxa blanca o que la relació ens sigui desfavorable. I es puntua favorablement que o bé se‟ns bloquegi una fitxa vermella o bé que la distància relativa ens sigui favorable. b) Autobloqueig De la mateixa manera que en el cas anterior tindrem en compte la distancia relativa entre les dues fitxes, però penalitzant amb un factor 2 el fet d‟autobloquejar-se una fitxa amb punt blanc. Camí Lliure: Una de les possibilitats per aconseguir guanyar una partida consisteix en trobar un camí lliure. Entenem per un camí lliure l‟absència de fitxes que obstaculitzin el camí que ha de fer una fitxa per arribar a l‟altre extrem del tauler. Això només ens serà favorable si la nostre fitxa és blanca. Les puntuacions que donarem són les següent: Valor Puntuació Camí Lliure Meu 200 Camí Lliure Seu -200 Camí Lliure Meu-Seu Avantatge 200 Camí Lliure Meu-Seu Desavantatge -200 O en es puntua molt favorablement el trobar un camí Lliure, i molt desfavorablement que l‟adversari tingui un camí lliure (sense tenir en consideració el color de la seva fitxa). Hi ha un petit matís en aquest càlcul, si s‟arriba a una solució en que els dos jugadors tenen un camí lliure, guanya aquell que li queden menys caselles per recorre. Funció avaluadora: Per acabar, quan tenim tots els valors calculats cal ponderar uns respecte dels altres. Hem seguit la ponderació descrita en la següent taula: Valor Factor Multiplicador Mortes Teves -3 Mortes Adversari +3 Amenaça Nivell 1 -2 Amenaça Nivell 2 +1.5 Amenaça Nivell 3 -3 Amenaça Nivell 4 1 Bloqueig Fitxa Adversari 1 Autobloqueig -1 Camí Lliure Teves +1 Camí Lliure Adversari -1 Capítol 6 Intel·ligència Artificial 92 6.6.1.4. Profunditat Al tractar-se d‟un joc amb pocs successors podem arribar sense cap problema a una profunditat 7 en jugades amb menys de 5 fitxes mortes, i a profunditat 9 en els altres casos. Hem escollit una valor senar, per així avaluar els estats on l‟última jugada simulada correspon a la del jugador que se li està calculant el moviment. El temps aproximat d‟execució es com a molt de sis o set segons, amb la qual cosa no generem molta ansietat en el contrincant humà. 6.6.2 Arepo A diferència dels jocs Sator i Tenet, en el joc Arepo hi intervenen 4 jugadors. Això podria fer pensar que caldria modificar l‟algoritme Minimax per adaptar-lo a aquesta situació, però a la realitat això no cal. Si es realitza una partida utilitzant les regles RV123, podem veure el joc com un enfrontament entre 2 jugadors, ja que els jugadors encarats van junts. Per altra banda tenim les regles RV2, on s‟hi que ha calgut modificar mínimament l‟algoritme per representar que tots els altres jugadors són enemics, en un mode “tots contra mi”. Això probablement no representa amb exactitud la realitat, ja que es podrien donar aliances momentànies que beneficiïn a dos adversaris, però a efectes pràctics ja aconseguim uns bons resultats sense tenir en compte aquest matís. 6.6.2.1 Successors Per obtenir els estats successors d‟un estat donat, cal realitzar tots els moviments vàlids pel jugador que en aquest moment li toqui tirar. Simplement s‟obtenen les posicions vàlides per totes les fitxes del jugador, i s‟actualitza l‟estat per cada moviment possible. 6.6.2.2 Heurístic Hem dissenyat un heurístic per cada tipus de regla que té el joc. Una de les característiques principal d‟aquest joc que ens va comentar precisament l‟Oriol Comas i Coma, i que hem pogut constatar en fer-hi partides, és que utilitzar una tàctica ofensiva és molt millor que no pas una de defensiva. Ara bé, què entenem per una tàctica ofensiva?, doncs és aquella que prioritza matar i amenaçar fitxes de l‟adversari. Aquesta conducta podem representar-la a l‟heurístic donant un valor més alt per aquelles situacions que denotin una actitud ofensiva. Això ho aconseguim donant un puntuació més elevada a matar fitxes a l‟adversari que no pas a que et matin fitxes, d‟aquesta manera aconseguim que en la 23 Veure les regles del joc al final de la memòria Capítol 6 Intel·ligència Artificial 93 decisió de matar o no matar, optem per matar. Aquest serà el mètode d‟actuació per l‟heurístic associat a les regles RV1. En canvi amb l‟heurístic de les regles RV2 no és tan obvi que seguir una tàctica ofensiva condueixi a obtenir millors resultats, ja que de la mateixa manera que a mi em convé matar fitxes d‟un dels adversaris, qualsevol dels dos altres rivals també en sortirà beneficiat. Un cop explicat el camí a seguir per cada un dels heurístics passaré a comentar quins càlculs hem utilitzat en cada un d‟ells. S‟utilitzaran imatges descriptives pels diferents càlculs des del punt de vista del jugador 1, però poden ser interpretades per qualsevol del punts de vista dels altres tres jugadors. Regles RV1 Per realitzar una tàctica ofensiva ponderarem amb un valor més gran totes aquelles situacions que afavoreixin matar una fitxa de l‟adversari tot i que això pugui comportar que alguna de les nostres fitxes pugui quedar amenaçada. Les regles ens diuen que el jugador 1 i 2 van junts contra el jugador 3 i 4, per tant a l‟hora de crear l‟heurístic es tindrà en compte les dos parelles per realitzar els càlculs. Una situació serà beneficiosa pel jugador 1 si també ho és pel jugadors 2, i per la mateixa raó una situació serà bona pel jugador 3 si ho és també pel jugador 4. A continuació exposarem els diferents càlculs que hem realitzat agrupant-los en diferents grups: Mortes Es tenen en compte el nombre de fitxes mortes per cada jugador, donant la següent puntuació: Valor Puntuació Fitxa Morta Parella Teva 40 Fitxa Morta Parella Adversaria 50 Amenaces Distingim 4 tipus d‟amenaces, les directes, les futures versió 1, les futures versió 2, i les futures resguardades (veure la figura 6.6) Figura 6. 6 Amenaces Arepo Capítol 6 Intel·ligència Artificial 94 Per totes elles utilitzarem la següent taula de valors: Valor Puntuació Fitxa Amenaçada Teva 10 Fitxa Amenaçada Adversari 15 Fitxa Amenaçada Doble 3 On assignarem una valor més elevat al fet d‟amenaçar una fitxa del adversari, i un plus extra per cada fitxa que tingui més d‟una amenaça. a) Amenaces Directes Un moviment per part de l‟adversari pot matar una de les teves fitxes. En el càlcul s‟ha de tenir en compte els atacs que poden arribar de les dues possibles diagonals (veure primera imatge de la figura 6.6). b) Amenaces Futures V1 Es dóna quan un moviment per part de l‟adversari produeix una amenaça directa sobre les teves fitxes (veure segona imatge de la figura 6.6). És un cas favorable ja que tindràs l‟oportunitat d‟eliminar aquesta fitxa en el següent torn (només es tindrà en compte les amenaçades en el sentit favorable del moviment). c) Amenaces FuturesV2 Es produeix quan un moviment per la teva part implica que et trobes amenaçat per una fitxa de l‟adversari. En aquest tipus d‟amenaça hem aplicat un factor multiplicador d‟1.5 quedant la taula exposada anteriorment de la següent manera: Valor Puntuació Fitxa Amenaçada Teva +15 Fitxa Amenaçada Adversari +22.5 Fitxa Amenaçada Doble +4.5 Aquesta modificació ve donada per la següent raó: quan et trobes en aquest cas és recomanable no moure la teva fitxa ja que el més provable és que l‟adversari decideix matar-te-la si la mous una posició endavant. L‟inconvenient principal es que tens bloquejada la fitxa de l‟adversari impedint que la pugui moure, i només la podrà moure quan tu avancis la teva fitxa. Arribat a aquest cas, només mouràs la teva fitxa si és indispensable fer-ho, quedant la teva fitxa com si estigues bloquejada. d) Amenaces Futures Resguardades: Comporta que un moviment endavant de l‟adversari condueix irremediablement al cas anterior (veure quarta imatge de la figura 6.6). Capítol 6 Intel·ligència Artificial 95 Bloquejades En aquest cas es tenen en compte les fitxes bloquejades per un mateix, és a dir, fitxes que bloquegin el pas d‟una mateixa parella com es pot veure en la figura 6.7. Figura 6. 7 Autobloqueig On donem les següents puntuacions: Valor Puntuació Auto bloquejades Teves -10 Auto bloquejades Adversari +10 Guanyadores Anomenem fitxes guanyadores a aquelles fitxes que han complert el seu objectiu arribant a l‟altre extrem de la seva línea de sortida. Es tracta de fitxes especials, ja que tot i que no les podem moure més durant la partida, tampoc poden ser matades, i en finalitzar la partida seran les encarregades de donar el guanyador final. Donem la següent puntuació: Valor Puntuació Guanyadores Teves +30 Guanyadores Adversari -30 Funció avaluadora: Per obtenir-ne el resultat final, fem una suma de tots els valors obtinguts, assignant valors positius i negatius per cada un dels casos anteriors de la següent manera. Tipus Factor multiplicador Mortes Teves -1 Mortes Adversari 1 Amenaçades Teves -1 Amenaçades Adversari 1 Amenaçades FuturesV1 Teves -1 Amenaçades FuturesV1 Adversari 1 Amenaçades FuturesV2 Teves -1 Amenaçades FuturesV2 Adversari 1 102 Capítol 7 Comunicació sense fils 103 Capítol 7 Comunicació sense fils En aquest capítol explicarem amb més detall el disseny, les funcionalitats i quines decisions hem pres a l‟hora de realitzar la implementació d‟una comunicació sense fils entre dues consoles Nintendo DS. 7.1 Biblioteca liblobby En les últimes actualitzacions de la biblioteca PAlib han inclòs una sèrie de biblioteques extres per ampliar-ne considerablement les seves funcionalitats. Entre totes elles podem trobar la liblobby; una biblioteca que ens ofereix tot una sèrie de funcionalitats bàsiques per implementar una comunicació sense fils entre dues o més consoles Nintendo DS. Passarem a descriure els tipus de dades que ens ofereix la biblioteca i que utilitzarem en el nostre sistema: User: És el tipus de dades bàsic en el protocol de comunicació sense fils. Encapsula la informació de les diferents consoles que participen en la comunicació, de les quals en podem obtenir el nom i l‟estat online o offline. Internament s‟utilitza per emmagatzemar totes les dades necessàries per poder enviar un missatge a qualsevol de les consoles que participen en una comunicació. Room: Representa el que anomenaríem una sala de joc, on es permet que usuaris hi entrin i en surtin. L‟avantatge d‟utilitzar aquesta estructura és que facilita la comunicació entre els usuaris que participen en una partida concreta, ja que podem enviar un missatge a tots ells a través de la pròpia sala. Per tant tenim identificats inequívocament tos els usuaris que participaran en una partida facilitant-ne així la comprovació de l‟estat de cada un d‟ells . Un cop tenim clars els tipus de dades que utilitzarem, cal familiaritzar-se amb la metodologia seguida per les biblioteques per dur a terme la comunicació. La mecànica és senzilla i consisteix en definir: Capítol 7 Comunicació sense fils 104 Una funció de recepció: que tractarà de manera immediata tot els missatges rebuts (veure figura 7.1). Una funció d‟enviament: en la que s‟especificarà l‟usuari de destí, l‟identificador de la funció de recepció (en el nostre cas la identificada amb 0x0001), el missatge a enviar, i la longitud d‟aquest (veure figura 7.2). Wifi Wifi repMissatge(missatge, longitud, usuariProcedencia) tractamenMissatge() enviarMissatge(missatge) LOBBY_SenToUser(usuariDesti, idRecepcio, missatge, longitud) Figura 7. 1 Funció de recepció Figura 7. 2 Funció d’enviament Amb totes aquestes dades ja podem començar a dissenyar el nostre sistema de comunicació. 7.2 Recepció de dades Utilitzarem una única funció de recepció de dades per tractar tots els missatges rebuts. Això comporta que caldrà identificar prèviament quin tipus de missatges hem rebut per així tractar-lo correctament. Tenint en compte que un missatge s‟implementa mitjançant un vector de caràcters, utilitzarem la primera posició d‟aquest vector per indiciar el tipus de missatge. A la taula 7.1 podem veure els diferents tipus de missatges que tindrem i el seu identificador. Tipus Missatge Id Configuració de la partida 1 Configuració Inicial de fitxes 2 Moviment Sator i Arepo 4 Moviment Tenet 6 Enviar Player Inicial Arepo 7 Informació Fi de Partida 9 Avís de Creació de Sala 10 Avís de tancament de Sala 11 Taula 7.1 Tipus de missatges Definim missatges per informar de quin tipus de partida ha de començar (joc escollit i opcions), quina configuració de fitxes inicials s‟ha escollit pels jocs Sator i Tenet, quin moviment s‟ha produït durant la partida, condicions de sortida (com reiniciar-la o sortir-ne), i un avís de creació i tancament de sala. Capítol 7 Comunicació sense fils 105 Una de les raons d‟introduir un missatge que ens indiqui quan una sala s‟ha creat i quan s‟ha tancat, es basa en que disposem de mètodes per crea una sala però no per tancar-la de forma definitiva. Això comporta que si utilitzem exclusivament les funcionalitats de les biblioteques, ens trobem que un usuari continua veient una sala com activa, tot i que el host l‟hagi volgut tancar. Per tal de solucionar aquest problema va ser necessari complicar una mica el disseny i introduir notificacions explícites quan una sala és creada i quan és tancada. 7.3 Establiment de Connexió Hem dissenyat tota la comunicació amb la idea d‟establir una connexió de fins a quatre usuaris diferents, però donats uns problemes que van sorgir i que seran comentats en l‟últim apartat d‟aquest capítol, es va fer necessari limitar el nombre de jugador a només dos. A l‟hora d‟establir una connexió entre diferents consoles cal diferenciar els tipus d‟usuaris que podem tenir: El host: serà l‟encarregat de crear la sala i el responsable d‟escollir totes les opcions de configuració d‟una partida. L‟usuari connectat: entrarà en una sala i esperarà que el host esculli les dades de la partida. Per tant caldrà definir els dos rols que poden tindrem durant una comunicació sense fils. Utilitzarem diagrames de seqüència per mostrar les classes participants en cada un dels rols. a) Host: Figura 7. 3 Diagrama de seqüència Host. Capítol 7 Comunicació sense fils 106 El host iniciarà la comunicació sense fils creant una sala i mostrarà per pantalla els usuaris que hi ha dintre de la sala. Enviarem una senyal periòdica per notificar a la resta d‟usuaris que hem creat una sala, cada 3 segons. El fet de veure‟ns obligats a enviar un avís a la resta d‟usuaris notificant de forma explícita la creació d‟una sala, en fa indispensable el seu enviament de forma periòdica, ja que si un usuari inicia la seva consola posteriorment a la creació d‟una sala, no podria rebre l‟avís de creació si aquest només fos enviat un cop es crea la sala. Un cop la sala ha estat creada, el host pot interaccionar amb el sistema per tancar la sala creada, enviant una senyal de cancel·lació a la resta d‟usuaris, o bé acceptant i continuant la configuració de la partida si un altre usuari ha entrat a la sala, enviant també una avís a la resta d‟usuaris comunicant que ja no s‟accepten més usuaris dintre de la sala. b) Usuari: Figura 7. 4 Diagrama de seqüència buscar sala L‟usuari busca si hi ha alguna sala creada consultant si ha rebut algun avís de creació de sala. Un cop identifica una sala pot decidir entrar-hi o no. Un cop el host ha acceptat el jugador que ha entrat a la sala, és l‟encarregat d‟escollir totes les opcions de la partida (amb el mateix menú que ens sortiria si féssim una partida multi jugador). Mentrestant l‟altre usuari espera un missatge del host, ja es tracti d‟una avís de tancament de la sala, o de les dades pertinents per iniciar una partida. Sí per alguna circumstancia decideix no esperar les dades del host i sortir de la sala creada, envia un avís al host notificant la seva sortida. 7.4 Començant a jugar En primer lloc cal comentar que totes les decisions de la partida correran a càrrec del host; sent ell l‟encarregat d‟escollir reiniciar o sortir d‟una partida mitjançant Capítol 7 Comunicació sense fils 107 el menú de pausa o escollint l‟opció pertinent en acabar una partida. En cas que un dels dos usuaris es desconnecti, és a dir, tanqui la consola, l‟altre participant rebrà un avís de desconnexió i la partida finalitzarà. Una de les decisions que hem pres en tots tres jocs, i que creiem que ha estat la més encertada, és situar les fitxes de cada un dels jugadors com si féssin una partida individual, és a dir, en cas del Sator i l‟Arepo les seves fitxes seran sempre les de la part inferior de la pantalla, i en el joc Tenet les de la diagonal superior esquerra. En tots els casos es respectarà la disposició establerta pel host, és a dir, si el host determina que el jugador que s‟ha connectat a la partida li correspon ser el jugador tres en el joc Arepo, el jugador que s‟ha connectat veurà que controla les fitxes de color groc a la part inferior de la pantalla, i que el jugador host està situat a la seva dreta (veure figura 7.5). Figura 7. 5 Vistes disposició fitxes Host i User També s‟ha cregut convenient que tots dos usuaris visualitzin a la pantalla superior exactament la mateixa informació; tots ells veuran el nom dels jugadors en la mateixa situació i que les fitxes mortes durant el joc també es situaran en les mateixes posicions. Un cop explicats les decisions preses a l‟hora de mostrar els elements gràfics per pantalla, ens centrarem en el desenvolupament de la pròpia partida, diferenciant per una banda el Sator i el Tenet, i per l‟altre l‟Arepo. 7.4.1 Sator i Tenet El joc Sator i Tenet requereixen una fase d‟inicialització prèvia, el en cas del Sator sempre i en el cas del Tenet només quan les opcions de partida així ho defineixin. S‟han pres les següents decisions per cada un dels jocs: -Sator: Els dos jugadors inicialitzen les posicions inicials de les seves fitxes, i en acabar esperen que l„altre jugador els hi enviï la seva configuració -Tenet: el host inicialitza les posicions inicials de les fitxes, mentre l‟usuari connectat espera rebre la configuració inicial. Un cop s‟han inicialitzat les posicions inicials el desenvolupament de la partida és senzill; el jugador que li toca tira primer realitza el mateix moviment que realitzaria Capítol 7 Comunicació sense fils 108 durant una partida qualsevol en el mode individual, mentrestant es mostra un missatge al seu adversari conforme s‟està esperant el seu moviment. Les dades que enviem són l‟identificador de la fitxa moguda i la posició a on es mou, i en el cas del Tenet també s‟envia l‟identificador de la carta que s‟utilitza. L‟altre usuari captura les dades, i actualitza l‟estat del sistema i la pròpia interfície del joc, tenint en compte que s‟han de recalcular les posicions rebudes per ajustar-les a la configuració pròpia de cada una de les consoles. 7.4.2 Arepo A diferencia dels altres dos jocs, en l‟Arepo hi poden participar fins a 4 jugadors diferents, dos jugadors humans, i dos controlats per la IA, amb la qual cosa es fa necessari que un dels usuaris faci els càlculs pertinents als moviments de les IA i els enviï a l‟altre. De la mateixa manera que hem actuat anteriorment, deixarem aquesta tasca al host, sent ell l‟encarregat de calcular els moviments de la IA i enviar-los a l‟altre usuari. A més a més el joc també té una altra peculiaritat, hem de calcular quin jugador tira primer aleatòriament. L‟encarregat de calcular i notificar quin usuari tira primer serà el host mentre l‟altre usuari espera rebre aquesta informació. Les dades enviades són exactament les mateixes que en el joc Sator, és a dir, identificador de fitxa i posició. 7.5 Problemes Bona part dels problemes que ens hem trobat a l‟hora d‟implementar la comunicació sense fils, causant un endarreriment en el projecte, venen donats per una falta de documentació precisa de la biblioteca, l‟existència únicament de dos exemples que mostrin la metodologia a seguir, una simplicitat massa acusada en algunes funcionalitats, la no reestructuració interna en produir-se desconnexions, i altres problemes que han anat sorgint a mesura que s‟han anat realitzant proves. En comentarem alguns d‟ells: Un cop escollida l‟opció de compilació24, era d‟esperar que poguéssim reproduir música en format mod, i utilitzar la biblioteca liblobby per la implementació d‟una comunicació sense fils. Però apareixia un estrany problema, ja que era impossible fer sonar la música. Investigant dintre de les pròpies biblioteques, vaig descobrir que sinó s‟inicialitzava la comunicació sense fils prèviament era impossible fer sonar la música. El principal problema que això comportava es que havíem d‟inicialitzar totalment la comunicació sense fils tot i no necessitar24 Veure més detalls al capítol 5. Capítol 7 Comunicació sense fils 109 la, i si no era inicialitzada completament, quan executàvem el joc a la consola Nintendo DS, aquest anava reservant espai memòria ininterrompudament, i en sobrepassar els 4MB de ram disponibles el joc es quedava penjat. Si s‟intenta provar el joc en un entorn amb moltes xarxes sense fils, un cop inicialitzada la comunicació sense fils, la consola quedava totalment bloquejada. Aquest error el vaig detectar per primer cop a la pròpia facultat, i no li vaig donar la importància que requeria pensant que es devia a alguna peculiaritat de la xarxa sense fils de la UPC. El problema va tornar a sorgir setmanes més tard però aquest cop a casa. El problema principal és que la consola no quedava bloquejada en inicialitzar la comunicació sense fils sinó al cap d‟alguns minuts, i per tant no associàvem aquest problema amb el que succeïa a la facultat. El problema quedava resolt quan ens allunyàvem de la font d‟interferències; en el meu cas el pati de casa. He intentat descobrir quin és el tipus de xarxa que produeix interferències però m‟ha estat impossible de localitzar. Aquesta és la raó principal d‟incloure en el DVD adjunt a aquesta memòria dos fitxers diferents, un conté implementada la comunicació sense fils i l‟altre no. Si inclogués exclusivament el joc que conté implementat la comunicació sense fils no podria assegurar amb total certesa que aquest funcionés en qualsevol lloc. Un enviament constant de dades pot provocar que la consola es bloquegi. L‟enviament pot ser tant de forma directa, és a dir, tu envies dades de forma constant voluntàriament, o de forma indirecta, per exemple consultant el nom d‟altres consoles que detectis que tenen activat la comunicació sense fils. Quan es produeixen partides amb més de dos jugadors, per algun motiu que no he sabut detectar, un avís de timeout pot aparèixer en una de les consoles indicant que s‟ha desconnectat. El problema és que aquest avís de desconnexió apareix quan cap de les consoles s‟ha desconnectat, i només és rebut per algunes de les consoles participants. Es va poder determinar que en esperar un temps prudencial de mig segon era possible tornar a veure la consola que en teoria s‟havia desconnectat com a connectada, però ens era impossible comunicar-nos amb ella. Aquesta és la principal raó per decidir finalment no permetre partides de més de dos jugadors en el nostre joc. Totes les funcionalitats que ens permeten consultar el nombre d‟usuaris (ja sigui en una sala, les consoles que han iniciat una comunicació sense fils, etc) no Capítol 7 Comunicació sense fils 110 tenen mai en compte si un usuari s‟ha desconnectat. Amb la qual cosa hem de comprovar sempre la validesa de les dades rebudes. Les estructures internes que representen el tipus de dades User, no s‟actualitzen convenientment, fent inviable que un cop una consola ha estat detectada com ha desconnectada, poder-s‟hi tornar a comunicar. Per accedir als diferents membres d‟una sala s‟utilitza un identificador numerat creixentment, és a dir, el host és identificat com l‟usuari número zero de la sala, el primer usuari en connectar-s‟hi s‟identifica amb el número u, el segon usuari amb el número dos, i així per la resta d‟usuaris. El problema es dóna quan un usuari decideix sortir d‟una sala creada, ja que no es produeix cap reestructuració dels identificadors dels usuaris que hi ha dintre de la sala, amb la qual cosa no és possible identificar tots els usuaris d‟una sala amb els identificador entre zero i el nombre d‟usuaris que hi ha en aquests moment a la sala. Capítol 8 Proves 111 Capítol 8 Proves L‟etapa de proves és l‟encarregada de determinar si la implementació del nostre sistema satisfà correctament les funcionalitats, les restriccions i l‟especificació que hem realitzat en etapes anteriors. És important remarcar que la fase de prova és una de les més importants, ja que és l‟etapa on es detecta la presencia de possibles errors en el nostre sistema. Les proves que podem fer en el nostre sistema són:  Proves unitàries: Es realitzen proves per cada component del sistema. Ja es tracti d‟una única classe o d‟un conjunt de classes relacionades entre elles.  Proves d‟integració: Es realitzen proves per veure el correcte funcionament de la comunicació entre les capes del nostre sistema.  Proves del sistema: Es realitzen proves globals del funcionament de tot el sistema.  Proves de validació: Ens permeten comprovar si efectivament es compleixen els requisits proposats pel nostre sistema. Una de les particularitats que sorgeix en aquesta etapa quan estem desenvolupant per un hardware específic, és que necessitem agilitzar la prova del codi compilat. Gràcies als emuladors podem aconseguir executar aquest codi en el propi ordinador, però l‟inconvenient sorgeix quan hem de provar funcionalitats que ens és impossible comprovar en un emulador. És el cas de la prova dels mètodes de guardat i de comunicació sense fils, ja que han de ser executats directament a la consola Nintendo DS. Això fa que la prova d‟aquestes funcionalitats s‟allargui considerablement. Una de les proves que va comportar més mal de caps va ser la prova de la comunicació sense fils implementada, ja que era necessari executar el nostre codi en dues consoles diferents, i per comprovar els errors de timeout exposats en el capítol 7, calia en alguns casos l‟espera de 40 o 50 minuts per prova. Capítol 9 Conclusions 118 9.4 Modificacions futures Tot i que el projecte ha assolit satisfactòriament els objectius plantejats, aquest pot ser millorat en alguns aspectes. Algunes ampliacions que podríem introduir en el joc són: Implementació d‟un nou mode de joc, que oferís a l‟usuari la possibilitat de realitzar partides a través d‟Internet amb un altre usuari. Incloure altres jocs de taula. Permetre partides de fins a 4 jugadors en el joc Arepo, utilitzant la comunicació sense fils de la consola. 9.5 Conclusions finals Durant el transcurs d‟aquest projecte hem pogut comprovar que el desenvolupament d‟un projecte d‟aquesta envergadura és un procés complex que requereix d‟un gran esforç i dedicació. A més a més si es té en compte que hem desenvolupat el projecte sobre un hardware específic com és la consola Nintendo DS, i que no havíem tingut cap contacte previ amb el desenvolupament de jocs per consoles, ens hem trobat en una situació nova per nosaltres ja que començàvem des de zero. El procés d‟aprenentatge d‟una nova tecnologia sempre comporta una motivació, i si es suma el fet de desenvolupar el joc per la consola Nintendo DS m‟he trobat amb una motivació extra, ja que sempre havia volgut entrar en aquest món del desenvolupament per consoles, però mai havia decidit donar el primer pas. He pogut comprovar els problemes que comporta desenvolupar jocs per consoles, ja que en molts casos t‟has d‟adaptar a les limitacions d‟aquesta i trobar solucions per problemes específics que et puguin sorgir i que en un principi ni et podies imaginar. És el cas dels problemes que he tingut amb la comunicació sense fils de la consola o els problemes que han sorgit en implementar tot l‟apartat gràfic del joc. A més a més també ens hem introduït en món de les intel·ligències artificials, que tot i que ja havíem tingut un primer contacte durant la carrera, ens ha permès comprovar exactament quina és la metodologia que segueixen molts dels jocs de taula que han sortit per ordinador i per consoles. Per tot plegat crec que ha sigut una experiència molt positiva, i encara més si es té en compte que un a gaudit i espera seguir gaudint del món dels videojocs. Annex 1 Regles dels jocs 119 Annex 1 Regles dels jocs Sator Un joc d‟Oriol Comas i Coma per a dos jugadors Sator (“sembrador” en llatí) és la primer paraula del quadrat màgic, una frase palindròmica en llengua llatina formada per cinc paraules de cinc lletres que es disposaven en una rajola de 5x5 caselles i que ha donat lloc a un gran nombre de jocs de paraules. El quadrat màgic és, doncs, un dels primers taulers de 5x5 caselles de què tenim notícia. Material − Un tauler de 5x5 caselles. − Cinc fitxes per a cada jugador, de les quals tres tenen a la part de sota un punt blanc i dues un punt vermell. Objectiu Fer arribar una fitxa amb punt blanc a la línia de sortida de l‟altre jugador. Preparació del joc El tauler es posa entre els dos jugadors. Cada jugador agafa les cinc fitxes d‟un color i les col·loca a les caselles de la línia que té davant seu, una a cada casella, amb els punts a la cara de sota de les fitxes, sense que l‟altre jugador sàpiga on ha posat les fitxes amb punt blanc i punt vermell. Annex 1 Regles dels jocs 120 Regles Comença el jugador de les fitxes negres i després es juga per torns. Les fitxes es mouen avançant un espai endavant en línia recta cap a una casella buida. També poden capturar: si una fitxa té en una casella en diagonal davant seu una fitxa de l‟adversari, la pot capturar i ocupar el seu lloc. La fitxa capturada es treu del tauler i no participa més en la partida. Ara bé, si la fitxa capturada té un punt vermell, també elimina la fitxa que l‟ha capturat. No es pot mirar si el punt de la fitxa que captura és vermell o blanc. Les dues fitxes es treuen del tauler. Jugar és obligatori, però capturar no. Un jugador sempre pot mirar la cara de sota de les seves fitxes, si no recorda on estan els punts vermells i blancs. Si un jugador no pot moure cap fitxa, l‟altre va jugant fins que el primer pot moure alguna fitxa. Final de partida Un jugador guanya la partida quan aconsegueix fer arribar una fitxa amb punt blanc a la línia de sortida de l‟altre jugador. Si arriba una fitxa amb el punt vermell no passa res, se segueix jugant. Si cap jugador no ha aconseguit fer arribar una fitxa amb punt blanc al final del tauler i no es poden moure més fitxes, guanya el jugador que té les fitxes més avançades. Arepo Un joc d‟Oriol Comas i Coma per a dos o quatre jugadors Material − Un tauler de 7x7 caselles. − Vint fitxes de quatre colors diferents, cinc per a cada jugador. Objectiu Fer arribar el màxim de fitxes al costat oposat de la línia de sortida (Regles V1). Ser el primer a fer arribar una fitxa al costat oposat de la línia de sortida (Regles V2). Annex 1 Regles dels jocs 121 Preparació del joc El tauler es posa al mig de la taula, de manera que cada jugador tingui com a costat oposat el color de les seves fitxes. Cada jugador agafa les cinc fitxes d‟un color i les col·loca a les cinc caselles centrals de la línia que té davant seu, una a cada casella. Regles per a quatre jugadors (RV1) Els jugadors que estan encarats juguen plegats. Es tria a l‟atzar quin jugador comença i després es juga per torns en el sentit de les agulles del rellotge. Les fitxes es mouen avançant un espai endavant en línia recta cap a una casella buida. També poden capturar: si una fitxa té en una casella en diagonal davant seu una fitxa de qualsevol dels altres tres adversaris, la pot capturar i ocupar el seu lloc. La fitxa capturada es treu del tauler i no participa més en la partida. No es pot capturar en cap casella de les quatre línies exteriors del tauler. Si un jugador no pot moure cap fitxa, els altres van jugant fins que pugui moure alguna fitxa. Final de partida La partida acaba quan totes les fitxes han arribat al costat oposat de la seva línia de sortida o estan bloquejats. Guanya la parella que hi ha fet arribar més fitxes. Regles per a quatre jugadors (RV2) Cada jugador juga només per a ell. Guanya el primer que fa arribar una fitxa al costat oposat de la seva línia de sortida. Regles per a dos jugadors L‟únic que varia és cada jugador juga amb les fitxes de dos colors encarats. Tenet Un joc d‟Oriol Comas i Coma per a dos jugadors Material Un tauler de 5x5 caselles. Cinc peces per a cada jugador: rei, cavall, alfil, torre i dama dels escacs. Quinze cartes diferents per a cada jugador: 1 rei, 2 cavalls, 3 alfils, 4 torres i 5 dames. Les cartes indiquen quina peça es pot moure i quin moviment pot fer. Cada peça pot fer el seu moviment als escacs i els de les peces anteriors (per exemple, les tres cartes Alfil negre permeten moure l‟alfil negre una vegada com a rei, una com a cavall i una com a alfil). Annex 1 Regles dels jocs 122 Objectiu Eliminar les cinc peces de l‟adversari o tenir peces de més valor al final de la partida. Preparació del joc El tauler es posa entre els dos jugadors. Cada jugador col·loca les cinc peces del seu color com s‟indica a la il·lustració. A més, cada jugador agafa les quinze cartes del seu color i les estén cara amunt a un costat del tauler, de manera que els dos jugadors les vegin bé. Abans de començar, els jugadors es poden posar d‟acord en una altra posició inicial de la partida, en el benentès que les peces blanques i negres han d‟estar en ordre invers. Regles Comença el jugador que té les fitxes negres i després es juga per torns. En cada un, el jugador juga la carta del seu color que vol, és a dir, la gira i mou la peça corresponent el moviment que indica la carta, cap a una casella buida o cap a una casella ocupada per una peça de l‟adversari. Tots els moviments són els de les peces d‟escacs. Cada carta es pot jugar una única vegada. Exemple El jugador negre juga la carta que li permet al seu cavall moure‟s com un cavall i el moviment corresponent. Quan li torna a tocar moure, juga la carta que li permet fer el moviment del rei al cavall i mou una casella en qualsevol direcció. Ara el seu cavall no es podrà moure més en tota la partida. Les captures també es fan com als escacs, és a dir, si una peça acaba el seu moviment en una casella ocupada per una peça adversària, la treu del tauler i hi posa la seva. Si el jugador de la peça capturada encara en tenia cartes, les deixa al costat del tauler, com si ja les hagués fet servir. Annex 1 Regles dels jocs 123 Jugar és obligatori, però si un jugador no pot jugar perquè no li queden cartes vistes, l‟altre segueix jugant mentre pugui. Si un jugador no pot jugar perquè les peces que pot moure estan bloquejades per altres peces, les podrà tornar a jugar quan es desbloquegin. Final de partida Un jugador guanya la partida automàticament si aconsegueix eliminar les cinc peces de l‟adversari. Si la partida acaba després dels quinze moviments dels dos jugadors i encara hi ha peces dels dos jugadors al tauler, guanya el que té peces de més valor (rei=1 punt, cavall=2, alfil=3, torre=4, dama=5). 124 Annex 2 Manual d’usuari 125 Annex 2 Manual d’usuari Cóm executar el joc A l‟hora d‟executar el joc que s‟inclou el DVD tenim dues possibilitats: Utilitzar un emulador: Tal i com s‟ha comentat en el capítol 1 d‟aquesta memòria es recomana utilitzar l‟emulador NO$GBA pel correcte funcionament del joc. Utilitzar una targeta flash com les descrites al capítol 1. Controls Pantalla tàctil: Interaccionar amb el joc (menú i joc) START: Accedir al menú de pausa durant una partida en qualsevol dels tres jocs. Botó B: En el joc Sator s‟utilitza per veure el revers de les fitxes. Annex 2 Manual d’usuari 126 Menú de partides Toca la pantalla tàctil un cop iniciat el joc per accedir a la pantalla de selecció de partides. A la pantalla de selecció de partida pots realitzar les següents accions: Crear partida: Seleccioni el Slot buit on desitgi crear la seva partida i premi la fletxa . A continuació li apareixerà una pantalla on pot introduir el seu nom d‟usuari mitjançant el teclat. Un cop hagi introduït el nom premi el botó per crear la partida. Esborrar partida: Seleccioni el Slot de la partida que desitgi esborrar i premi el botó . A continuació apareixerà una pantalla per confirmar si desitja esborrar la patida. Carregar partida: Seleccioni el Slot que contingui la partida que vulgui carregar i premi el botó . Nota: Si s‟està utilitzant un emulador no compatible amb les opcions de guardat apareixerà una pantalla on s‟indicarà la impossibilitat de guardar. Annex 2 Manual d’usuari 127 Menú principal El menú principal inclou tres opcions: Individual: Seleccioni aquesta opció si desitja realitzar una partida contra la màquina. Multiplayer: Seleccioni aquesta opció per realitzar una partida multi jugador. Crèdits: Seleccioni aquesta opció si desitja veure els crèdits del joc. Partida Individual Un cop escollida la opció de realitzar una partida Individual seleccioni un dels tres jocs disponibles per passar a configurar les opcions de partida. 134 Bibliografia 135 Bibliografia [OCC] Pàgina web de l‟Oriol Comas i Coma, http://www.comascoma.com [LLI] Obtenir llicencia oficial de Nintendo, http://warioworld.com [DOC] Documentació Biblioteques PAlib, http://www.palib.info/wiki/doku.php [HOM] Fòrum biblioteques PAlib, http://forum.palib.info [LIB] Biblioteques libnds, http://libnds.devkitpro.org [PAL] Biblioteques PAlib, http://www.palib.info [GBA] NO$GBA Emulator, http://nocash.emubase.de/gba.htm [MOD] The Mod Archive, http://modarchive.org/ [IIA] Stuart J. Russell and Peter Norvin, Inteligencia Artificial un enfoque moderno Softcatalà, http://www.softcatala.org/recull.html Google, http://www.google.com Apunts Enginyeria del Software II Apunts Intel·ligència Artificial