Project Objectgericht Programmeren

Transcriptie

1 Project Objectgericht Programmeren Prof. Eric Steegmans Koen Vanderkimpen Academiejaar Deze tekst beschrijft de opgave voor het project van de cursus Objectgericht Programmeren. Dit project geldt als examen voor de cursus. Het project wordt bij voorkeur uitgewerkt in groepjes van 2 studenten. In dat geval moet de volledige opgave worden uitgewerkt. Het project mag ook individueel worden uitgewerkt. In dat geval moet slechts het aangegeven deel van de opgave worden uitgewerkt. Indien je het project uitwerkt met een andere partner dan je partner voor de practica, moet je dit vóór 15 mei melden in een aan Prof. Eric Steegmans. Na deze datum aanvaarden we geen wijzigingen meer in de samenstelling van de groepjes. Indien er in de loop van het project conflicten ontstaan waardoor een verdere samenwerking onmogelijk is, moet elk van de partners het project individueel uitwerken. Dergelijke veranderingen moeten onmiddellijk gemeld worden. Het project handelt over het bouwen van een deel van de kern van een roleplaying game (RPG) in een middeleeuwse setting. Het spel is gebaseerd op bestaande spellen. Alle grafische aspecten en alles in verband met gebruikersinteractie worden buiten beschouwing gelaten. Het project beperkt zich tot het uitwerken van die elementen, die in de kern van het softwaresysteem terug te vinden zijn. Meer bepaald moet het gevraagde systeem ondersteuning bieden voor het beschrijven van helden, monsters, wapens, harnassen,... In de opgave worden een aantal vereisten gesteld omtrent hoe deze elementen moeten worden ondersteund in het beoogde systeem. Op de eerste plaats worden een reeks functionele vereisten gesteld. Dit zijn eerder vage beschrijvingen van functionaliteiten die door het systeem moeten worden ondersteund. We verwachten dat je zelf de nodige basisfunctionaliteiten invoert zoals getters en setters voor karakteristieken. Verder zijn er een aantal niet-functionele vereisten, die zich richten op de kwaliteit van het beoogde systeem. Zo worden op diverse punten vereisten gesteld op het vlak van efficiëntie, aanpasbaarheid en herbruikbaarheid. 1

2 Opgave De volgende elementen uit het spel moeten door iedereen worden uitgewerkt: helden, monsters, rugzakken, geldbeurzen, dukaten, wapens en harnassen. 1 Wapens [Weapons] De protagonisten van dit spel - helden en monsters - kunnen wapens gebruiken om elkaar mee af te slachten. Wapens hebben de volgende kenmerken. 1.1 Identificatie [Identification] Elk wapen heeft een identificatie in de vorm van een groot geheel getal (type long in Java). Het identificatienummer van een wapen zal steeds een positief, even getal zijn, dat na de produktie van het wapen niet meer kan veranderen. Er wordt naar gestreefd om ieder wapen te voorzien van een uniek nummer, maar er is geen garantie dat dit inderdaad zo zal zijn. Er kunnen overigens ook andere soorten dingen in omloop zijn, waarvan het identificatienummer gelijk is aan dat van een wapen. Bij het aanmaken van een nieuw wapen zal het identificatienummer intern gegenereerd worden (het mag dus niet als argument aan de constructor worden meegegeven). Concreet moet je er voor zorgen dat je systeem op zijn minst verschillende identificatienummers zal genereren voor de eerste 1000 wapens die worden aangemaakt (dit feit op zich moet niet opgenomen worden in de specificatie). Alle methodes in verband met identificatienummers voor wapens en andere spelelementen moeten totaal worden uitgewerkt. 1.2 Gewicht [Weight] Elk wapen heeft een gewicht. Het gewicht van een wapen wordt bij het vervaardigen eens en voor altijd vastgelegd. Het spel zal nooit mogelijkheden bieden om het gewicht van wapens te veranderen. Uiteraard kan het gewicht van een wapen nooit negatief zijn. Alle methodes in verband met gewicht van wapens en andere spelelementen moeten totaal worden uitgewerkt. In het spel worden gewichten momenteel uitgedrukt in kilogram of in gram. Niets sluit uit dat later ook andere eenheden (zoals ponden) zullen gebruikt worden voor gewichten. Het invoeren van nieuwe gewichtseenheden mag geen wijzigingen impliceren aan de klasse van wapens. Indien je streeft naar een score van 80% of meer voor het project, moet het mogelijk zijn gewichten te registreren met 2

3 hoogstens 2 cijfers na de komma. Indien je niet streeft naar een dergelijke score, mogen gewichten als gehele getallen geregistreerd worden. 1.3 Waarde [Value] Elk wapen heeft een waarde. De waarde van een wapen wordt uitgedrukt in een hoeveelheid goudstukken (dukaten). Het is niet de bedoeling dat in de toekomst andere eenheden worden gebruikt om de waarde van wapens of andere spelelementen uit te drukken. Uiteraard kan de waarde van een wapen nooit negatief zijn. Doorheen het spel kan de waarde van een wapen zowel verminderen (vb. door slijtage) als vermeerderen (vb. door herstellingen). Alle methodes in verband met gewicht van wapens en andere spelelementen moeten totaal worden uitgewerkt. 1.4 Schade [Damage] Elk wapen wordt ten alle tijde gekenmerkt door de schade die het kan aanrichten aan de tegenstander in een gevecht. De schade die een wapen kan toebrengen kan variëren in de tijd. In de huidige versie van het spel wordt de schade voor alle wapens uitgedrukt als een geheel getal dat ligt tussen 1 en 20. Hoe hoger de waarde, hoe meer schade het wapen kan toebrengen. Het moet mogelijk zijn om in volgende versies van het spel de hoogst mogelijk waarde voor de schade aan te passen, zonder dat dit een impact heeft op andere klassen. Een nieuwe hoogste grenswaarde zal steeds van toepassing zijn op alle wapens. Die nieuwe hoogst mogelijke waarde moet op termijn at run-time kunnen berekend worden (vb. met behulp van een random getal). De laagst mogelijke waarde voor de schade zal ten alle tijde 1 zijn. Alle methodes in verband met de schade die wapens en andere spelelementen kunnen aanbrengen moeten nominaal worden uitgewerkt. 1.5 Eigenaar [Holder] Wapens kunnen worden vastgehouden door helden en monsters. Ze kunnen ook worden opgeborgen in rugzakken. Een wapen kan in een beginstadium los voorkomen in het spel (het kan bijvoorbeeld ergens op de grond liggen). Van zodra een wapen echter opgeborgen is in een rugzak of wordt vastgehouden door een held of monster, kan het niet langer meer los voorkomen. De enige mogelijkheid voor een held of een monster om zich te ontdoen van één van zijn wapens, is dat wapen te vernietigen of het over te dragen aan een andere held of monster. Dat laatste kan bijvoorbeeld door het al dan niet stiekem in de rugzak te steken van een andere held, door het in de handen te duwen van een andere held of monster,... 3

4 Alle methodes in verband met de eigenaar van wapens en andere spelelementen moeten defensief worden uitgewerkt. Daarbij moet gebruik gemaakt worden van een zelfgedefinieerde uitzonderingsklasse, waarvan de objecten gecontroleerde uitzonderingen (checked exceptions) zijn. Naast de gebruikelijke functionaliteit, moet het mogelijk zijn om de hoofdeigenaar van een wapen op te vragen. Dit is de eventuele held of het monster die het wapen vasthoudt, of die de rugzak vasthoudt waarin het wapen direct of indirect opgeborgen zit. 2 Harnassen [Armors] Harnassen zijn een mooi staaltje van middeleeuwse technologie. Harnassen kunnen ervoor zorgen dat een held geen of minder schade oploopt in een gevecht. Monsters zijn te dom om harnassen te maken. Ze kunnen wel harnassen met zich meesleuren, maar kunnen er geen effectief gebruik van maken. Harnassen hebben de volgende kenmerken. 2.1 Identificatie [Identification] Elk harnas heeft een identificatie in de vorm van een groot geheel getal (type long in Java). Het identificatienummer van een harnas zal steeds een positief priemgetal zijn, dat na produktie van het harnas niet meer kan veranderen. Bij het aanmaken van een nieuw harnas zal het identificatienummer door de gebruiker worden meegegeven. Er wordt naar gestreefd om ieder harnas te voorzien van een uniek nummer, maar er is geen garantie dat dit inderdaad zo zal zijn. Er kunnen overigens ook andere spelelementen (vb. wapens) in omloop zijn, waarvan het identificatienummer gelijk is aan dat van een harnas. 2.2 Gewicht [Weight] Elk harnas heeft een gewicht. Voor het gewicht van harnassen gelden dezelfde bepalingen als voor het gewicht van wapens. 2.3 Waarde [Value] Elk harnas heeft een waarde, die net zoals voor wapens wordt uitgedrukt in een hoeveelheid dukaten. De waarde van een harnas kan nooit negatief zijn. Doorheen het spel wordt de waarde van een harnas steeds bepaald door zijn hoogst mogelijke waarde (die onveranderlijk is en bepaald wordt bij produktie van het harnas) vermenigvuldigd met de procentuele beschermingsfactor van het harnas. (Voorbeeld: 4

5 een harnas met een hoogst mogelijke waarde van 1000 dukaten en een beschermingsfactor van 10 op een maximum van 20, heeft een huidige waarde van 500 dukaten). 2.4 Beschermingsfactor [Protection] Elk harnas heeft een beschermingfactor. Dit is een geheel getal dat in de huidige versie van het spel ligt tussen 1 en 20. De beschermingsfactor van een harnas kan niet meer veranderen na de produktie ervan. Het moet mogelijk zijn om na verloop van tijd verschillende soorten harnassen in te voeren, die elk een eigen vaste bovengrens hebben voor de beschermingsfactor (de ondergrens voor de beschermingsfactor zal steeds 1 zijn). Zo moet het bijvoorbeeld mogelijk zijn om na verloop van tijd onderscheid te maken tussen tinnen harnassen en bronzen harnassen, waarbij alle tinnen harnassen een maximale beschermingsfactor hebben van 15, en alle bronzen harnassen een maximale beschermingsfactor hebben van 28. Je mag vrij kiezen of je methodes in verband met de beschermingsfactor van harnassen en andere spelelementen totaal, nominaal of defensief uitwerkt. 2.5 Eigenaar [Holder] Harnassen kunnen, net zoals wapens, opgeborgen worden in rugzakken of worden vastgehouden door een held of een monster. Hiervoor gelden dezelfde bepalingen als voor wapens. Helden hebben daarenboven de intelligentie om een harnas aan te trekken, waardoor ze beter beschermd worden in gevechten. Helden kunnen nooit meer dan één harnas aantrekken. Uiteraard kunnen helden het harnas dat ze aangetrokken hebben ook terug uittrekken. Afgezien van het harnas dat ze eventueel dragen, kunnen helden nooit meer dan 2 harnassen meesleuren (direct in de hand of in rugzakken). Helden kunnen ook beslissen om een ander harnas dat ze meesleuren of ergens vinden aan te trekken. Zij zijn handig genoeg om in één beweging hun huidig harnas uit te trekken en een ander harnas aan te trekken. 3 Dukaten [dukats] In het spel zijn goudstukken of dukaten de enige munteenheid. Naast overleven, is het verzamelen van dukaten één van de belangrijkste doelstellingen van het spel. Dukaten worden ook gebruikt om de waarde van andere dingen, zoals wapens, harnassen en rugzakken uit te drukken. Alle dukaten die in het spel gebruikt worden zijn identiek. Ze hebben allen een gewicht van 50 gram, en kunnen niet worden vernietigd. Het moet niet mogelijk zijn om, na verloop van tijd, andere munteenheden in te voeren in het spel. 5

6 Dukaten kunnen worden weggestoken in rugzakken en in geldbeugels. Ze kunnen ook worden vastgehouden door helden en monsters. In tegenstelling tot andere elementen uit het spel, zoals wapens en harnassen, hebben dukaten geen weet van hun eventuele eigenaar. Met andere woorden, de associatie tussen dukaten en hun eigenaar moet uni-directioneel worden uitgewerkt. Indien je streeft naar een score van 80% of meer voor het project, verwachten we dat de hoeveelheid geheugen die nodig is om in het spel om te gaan met dukaten beperkt blijft. Concreet moet de totale hoeveelheid geheugen die nodig is voor dukaten in ieder spel constant zijn (i.e. onafhankelijk van het aantal dukaten dat er effectief in voorkomt). De hoeveelheid geheugen die nodig is om bij te houden hoeveel dukaten zich in een rugzak of in een geldbeugel bevinden, mag uiteraard variëren in functie van het aantal rugzakken en geldbeugels, die in het spel betrokken zijn, en mag zelfs variëren in functie van het aantal dukaten in één rugzak of geldbeugel (dat laatste enkel indien je niet streeft naar een constante hoeveelheid geheugen per geldbeugel). 4 Rugzakken [Backpacks] De helden van dit spel maken gebruik van rugzakken om op een handige manier hun bezittingen met zich mee te nemen. Een rugzak is dus iets waar men andere spullen kan instoppen, zoals wapens, harnassen, dukaten, geldbeurzen en zelfs andere rugzakken. Hierbij gelden uiteraard de regels van de fysica. Een rugzak heeft volgende kenmerken. 4.1 Identificatie [Identification] Elke rugzak heeft een identificatie in de vorm van een groot geheel getal (type long in Java). Het identificatienummer van een rugzak zal steeds een positief, oneven getal zijn, dat na de produktie van de rugzak niet meer kan veranderen. 4.2 Inhoud [Content] Een rugzak kan gebruikt worden om allerlei spullen zoals wapens, harnassen en dukaten in op te bergen. Een rugzak kan ook andere rugzakken en geldbeurzen bevatten. Helden en monsters kunnen zich nooit in een rugzak bevinden. Alle methodes in verband met de inhoud van rugzakken en andere spelelementen moeten defensief worden uitgewerkt. Je mag daarbij zelf kiezen welke uitzonderingsklasse(n) je daarbij gebruikt. Als je streeft naar een score van 80% of meer voor het project, moet het mogelijk zijn om in constante tijd het lichtste en het zwaarste ding op te vragen dat 6

7 zich in een rugzak bevindt. Verder moet dan ook het toevoegen van spullen aan een rugzak en het verwijderen van spullen uit een rugzak hoogstens een tijd O(log(N)) in beslag nemen. Indien nodig, mag je daarvoor extra beperkingen opleggen aan de inhoud van een rugzak. Tenslotte moet je voor een score van 80% of meer ook een methode uitwerken om de inhoud van een rugzak over te brengen naar een andere rugzak. Indien je niet streeft naar een score van 80% of meer, mag je vrij een gegevensstructuur kiezen, en moet er geen methode voorzien worden om de inhoud van een rugzak over te brengen naar een andere rugzak. De gebruikelijke functionaliteit omtrent de inhoud van een rugzak (vb. het toegevoegen en verwijderen van elementen) moet uiteraard wel worden uitgewerkt. 4.3 Gewicht [Weight] Elke rugzak heeft een eigen gewicht. Voor het gewicht van rugzakken gelden dezelfde bepalingen als voor het gewicht van wapens en harnassen. Naast het opvragen van het eigen gewicht, moet het mogelijk zijn het totale gewicht van een rugzak op te vragen, i.e. inclusief het gewicht van alle dingen die opgeborgen zijn in de betrokken rugzak. 4.4 Waarde [Value] Elke rugzak heeft een waarde. De waarde van een rugzak is steeds de som van de eigen waarde van de rugzak en van de waarde van alle dingen die er in opgeborgen zijn. Voor de eigen waarde van rugzakken gelden dezelfde bepalingen als voor de waarde van wapens. Die waarde kan dus nooit negatief zijn, en kan in de loop van het spel veranderen. 4.5 Capaciteit [Capacity] Elke rugzak heeft een capaciteit. De capaciteit van een rugzak wordt uitgedrukt in één of andere gewichtseenheid (kilogram, gram,...) en weerspiegelt het maximale gewicht van alle dingen die zich in de betrokken rugzak kunnen bevinden. De capaciteit van een rugzak wordt bij de produktie ervan eens en voor altijd vastgelegd. Het spel zal nooit mogelijkheden bieden om capaciteiten van rugzakken te veranderen. Hou er rekening mee dat het gewicht van sommige dingen in een rugzak kan veranderen, waardoor de capaciteit overschreden zou kunnen worden. Alle methodes in verband met de capaciteit van rugzakken en andere spelelementen moeten totaal worden uitgewerkt. 7

8 4.6 Eigenaar [Holder] Zoals wapens, harnassen en dukaten, kunnen rugzakken worden vastgehouden door helden en monsters. Rugzakken kunnen ook worden opgeborgen in andere rugzakken. In tegenstelling tot wapens en harnassen, kunnen rugzakken ten alle tijde los voorkomen in het spel (zij kunnen bijvoorbeeld ergens op de grond liggen). Helden en monsters kunnen op eender welk moment sommige van de rugzakken die ze vasthouden, laten vallen. Die rugzakken kunnen dan later terug worden opgepikt door hetzelfde wezen of door een ander wezen. 5 Geldbeurzen [Purses] Een geldbeurs dient om dukaten in op te bergen. Andere dingen kunnen niet worden weggeborgen in een geldbeurs. Geldbeurzen hebben volgende kenmerken: 5.1 Identificatie [Identification] Elke geldbeurs heeft een identificatie in de vorm van een groot geheel getal (type long in Java). Het identificatienummer van een rugzak zal steeds een getal zijn uit de reeks van Fibonacci (1,1,2,3,5,8,...). Het identificatienummer van een geldbeurs kan na de produktie van die geldbeurs niet meer veranderen. Indien je streeft naar een score van 80% of meer voor het project, verwachten we een formele specificatie zijn van alle methodes omtrent identificatienummers voor geldbeurzen. In het andere geval, volstaat een informele specificatie voor dit deel van het project. 5.2 Inhoud [Content] Een geldbeurs kan enkel gebruikt worden om dukaten in op te bergen. Wapens, harnassen, rugzakken, geldbeurzen, helden, monsters,... kunnen niet worden opgeborgen in een geldbeurs. Als je streeft naar een score van 80% of meer voor het project, moet de hoeveelheid geheugen die nodig is voor het opslaan van de inhoud van een geldbeurs gelijk zijn voor alle geldbeurzen. Indien je niet streeft naar een score van 80% of meer, mag de hoeveelheid geheugen verschillen van geldbeurs tot geldbeurs. Naast de gebruikelijke methodes omtrent de inhoud van een geldbeurs, moet er in ieder geval een methode voorzien worden om de inhoud van een geldbeurs over te brengen naar een andere geldbeurs. 8

9 5.3 Gewicht [Weight] Elke geldbeurs heeft een eigen gewicht. Voor het gewicht van geldbeurzen gelden dezelfde bepalingen als voor het gewicht van wapens, harnassen en rugzakken. Naast het opvragen van het eigen gewicht, moet het mogelijk zijn het totale gewicht van een geldbeurs op te vragen, i.e. inclusief het gewicht van alle dukaten die er in opgeborgen zijn. 5.4 Waarde [Value] Elke geldbeurs heeft een waarde. Deze waarde is steeds de som van de eigen waarde van de geldbeurs zelf en van de waarde van alle dukaten die er in opgeborgen zijn. Voor de eigen waarde van geldbeurzen gelden dezelfde bepalingen als voor de eigen waarde van rugzakken. Die waarde kan dus nooit negatief zijn, en kan in de loop van het spel veranderen. 5.5 Capaciteit [Capacity] Elke geldbeurs heeft zijn eigen capaciteit. De capaciteit van een geldbeurs wordt uitgedrukt in het aantal dukaten dat maximaal kan opgeborgen worden in de betrokken geldbeurs. De capaciteit van een geldbeurs wordt bij de produktie ervan ingesteld, maar kan in de loop van het spel veranderen. Iedere poging om meer dukaten in een geldbeurs op te bergen dan aangegeven door de capaciteit, resulteert in het scheuren van die geldbeurs. Een gescheurde geldbeurs kan niet meer hersteld worden, en alle opgeborgen dukaten vallen meteen op de grond. Dit geldt ook indien de geldbeurs op haar beurt opgeborgen zou zijn in een rugzak. Het scheuren van een geldbeurs impliceert ook dat de geldbeurs waardeloos wordt. Niets verhindert dat helden en monsters gescheurde geldbeurzen toch nog met zich meesleuren, hoewel het nut ervan erg klein zal zijn. 5.6 Eigenaar [Holder] Zoals andere spelelementen, kunnen geldbeurzen worden vastgehouden door helden en monsters. Geldbeurzen kunnen ook worden opgeborgen in rugzakken. Een geldbeurs kan ten alle tijde los voorkomen in het spel (ze kan bijvoorbeeld ergens op de grond liggen). Helden en monsters kunnen geldbeurzen ten alle tijde laten vallen. Ze kunnen dan later terug worden opgepikt door hetzelfde wezen of door een ander wezen. 9

10 6 Helden [Heroes] In dit soort computerspellen staan helden centraal. Helden vechten tegen monsters en verzamelen dukaten, wapens, harnassen en andere spelelementen. Helden zullen nooit onderling vechten. Helden hebben de volgende eigenschappen. 6.1 Naam [Name] Helden hebben steeds een naam. Deze bestaat uit minstens twee letters en mag in zijn geheel enkel letters, afkappingstekens ( ) en spaties bevatten. James o Hara is een voorbeeld van een geldige naam voor een held. We sluiten niet uit dat de regels omtrent de spelling van namen van helden later uitgebreid worden met andere tekens. De hierboven vermelde tekens zullen echter nooit weggenomen worden als geldige tekens in namen van helden. De naam van een held verandert niet meer na zijn geboorte. Je mag vrij kiezen of je methodes in verband met de naam van helden en andere spelelementen totaal, nominaal of defensief uitwerkt. 6.2 Ankers [Anchors] Helden hebben een aantal zogenaamde ankerpunten waarmee ze allerlei spullen met zich mee kunnen dragen. In de huidige versie van het spel heeft elke held precies 3 ankerpunten: een linkerhand, een rechterhand en een rug. Het moet echter mogelijk zijn om helden op termijn uit te breiden met bijkomende ankerpunten. Elk ankerpunt kan gebruikt worden om een wapen, een harnas, een rugzak, een geldbeugel of een dukaat mee te nemen. Aan een ankerpunt zullen nooit meerdere elementen kunnen bevestigd worden. Verder mag het totale gewicht van alle verankerde elementen de draagcapaciteit van de held (zie verder) niet overschrijden. Uiteraard moet het mogelijk zijn om een element te bevestigen aan een ankerpunt, om het element dat vastzit aan een ankerpunt te verwijderen, en om het element dat vastzit aan een ankerpunt te vervangen door een ander element. Verder moet het ook mogelijk zijn om de totale waarde van alle bezittingen van een held te kunnen opvragen. Alle methodes in verband met ankerpunten van helden en andere spelementen moeten defensief worden uitgewerkt. Bij zijn geboorte zal iedere held voorzien worden van een wapen in de rechterhand en een rugzak op zijn rug. In de rugzak zal zich een geldbeugel bevinden, waarin zich 1 tot 100 dukaten bevinden. Verder zal de held een harnas aangetrokken krijgen. Al deze elementen moeten intern in de constructor aangemaakt worden (ze mogen dus niet als argumenten aan de constructor worden meegegeven). De draagcapaciteit van de nieuwe held zal zodanig worden gekozen, dat hij minstens al deze spullen kan dragen. 10

11 6.3 Beschermingsfactor [Protection] Elk held heeft een beschermingfactor. Deze karakteristiek weerspiegelt hoe goed een held slagen kan ontwijken in gevechten. De beschermingsfactor van een held zal steeds een strikt positief geheel getal zijn. In de huidige, vereenvoudigde versie van het spel heeft elke held een standaard beschermingsfactor van 10, die niet kan veranderen in de loop van het spel. De echte beschermingsfactor van een held is dan gelijk aan die standaard waarde verhoogd met de beschermingsfactor van het eventuele harnas dat de held draagt. Er moet geen rekening gehouden worden met mogelijke aanpassingen aan het berekenen van de beschermingsfactor van helden in toekomstige versies van het spel. 6.4 Raakpunten [Hitpoints] Elke held heeft een beperkt aantal raakpunten. Raakpunten worden weergegeven door een natuurlijk getal. Bij de geboorte van een held worden hem een aantal raakpunten toegekend. In de huidige versie van het spel is dit aantal meteen ook het maximum aantal raakpunten dat de held ooit kan hebben. Het moet echter mogelijk zijn om in meer gevorderde versies van het spel het maximum aantal raakpunten van een held te verhogen. Alle methodes in verband met raakpunten van helden en andere spelelementen moeten nominaal worden uitgewerkt. De raakpunten van een held kunnen op diverse manieren afnemen. Zo vermindert het aantal raakpunten van een held telkens hij geraakt wordt in een gevecht door een monster dat voldoende krachtig is. Raakpunten van helden kunnen ook terug stijgen, maar kunnen uiteraard nooit de maximale waarde overschrijden. De raakpunten van een held kunnen onder ander verhogen op het einde van een gevecht waarin de held een monster heeft verslagen. Een dergelijke verhoging geeft aan dat de held van zijn opgelopen kwetsuren geheel of gedeeltelijk is hersteld. Het aantal raakpunten van een held kan ook verhogen doordat een monster met een negatieve kracht hem een rake slag toedient. Een held is volledig functioneel zolang zijn raakpunten positief zijn. Helden sterven wanneer hun raakpunten op 0 komen te staan. Een held die dood is, kan geen acties meer ondernemen. 6.5 Kracht [Strength] Elke held heeft ook ten alle tijde een indicatie van zijn kracht. De kracht van een held wordt weergegeven op een schaal van gehele getallen, waarbij de waarde 10 een gemiddelde kracht voorstelt. Daarbij zijn negatieve waarden niet uitgesloten. In deze vereenvoudigde versie van het spel is de kracht van iedere held onveranderlijk. Wanneer helden bovengemiddeld sterk zijn, brengen ze meer schade toe in gevechten; wanneer ze ondergemiddeld sterk zijn, brengen ze minder schade toe. 11

12 Dit wordt verder geconcretiseerd in de beschrijving van het slaan van tegenstanders. De kracht van een held bepaalt ook zijn maximale draagcapaciteit, i.e. het maximale gewicht van alle spullen die de held met zich mee kan dragen. De formule hiervoor is als volgt: 1. Helden zonder kracht kunnen niets met zich meedragen. 2. Voor helden met een kracht gelegen tussen 1 tot 10 is de draagcapaciteit gelijk aan de kracht van de held vermenigvuldigd met 10 kg. 3. Voor helden met een kracht tussen 11 en 20 gelden de volgende maximale waarden voor de draagcapaciteit: {115 kg, 130 kg, 150 kg, 175 kg, 200 kg, 230 kg, 260 kg, 300 kg, 350 kg, 400 kg}. 4. Voor helden met een kracht vanaf 21 is de maximale draagcapaciteit gelijk aan 4 keer de maximale draagcapaciteit van een kracht die 10 eenheden lager ligt. Bijvoorbeeld: een held met een kracht van 25 heeft een draagcapaciteit van 800 kg (i.e. 4 x 200 kg). 6.6 Slaan [Hit] Helden vechten enkel tegen monsters. Ze doen dit door het betrokken monster herhaaldelijk te slaan. In de context van dit project moet enkel het toebrengen van één slag door een held aan een monster worden uitgewerkt (zoals verder zal blijken, moeten gevechten enkel worden uitgewerkt in een hoofdprogramma). Het toebrengen van een slag door een held aan een monster verloopt als volgt: 1. Er wordt een getal gegenereerd tussen 0 en 20. Hiervoor kunnen bijvoorbeeld 4 dobbelstenen worden gegooid. De waarden in het bovenvlak van ieder van die dobbelstenen worden dan opgeteld en verminderd met 4. Andere manieren om een dergelijk willekeurig getal te bekomen zijn uiteraard ook toegelaten. 2. Het resulterend getal wordt vergeleken met de beschermingsfactor van het monster. Als het resulterende getal groter is dan of gelijk aan de beschermingsfactor van de tegenstander, dan is er raak geslagen. In het andere geval heeft de slag geen impact op het betrokken monster. 3. In het geval van een rake slag worden de raakpunten van het monster verminderd met de schade die de slag bij hem teweeg brengt. In de huidige versie van het spel, is de schade die een slag veroorzaakt de som van 2 getallen. Het eerste getal is de schade die het wapen kan aanrichten dat de held draagt 12

13 in zijn rechterhand. Als de held geen wapen draagt in zijn rechterhand is het eerste getal 0. Het tweede getal wordt bepaald door de kracht van de held. Dit getal wordt bekomen door de kracht van de betrokken held te verminderen met 10, en vervolgens te delen door 2, waarbij cijfers na de komma worden weggelaten. Merk op dat in extreme gevallen, de totale schade die een rake slag veroorzaakt negatief kan zijn, waardoor de raakpunten van het geslagen monster in de mate van het mogelijke verhogen. De regels omtrent de schade die een rake slag veroorzaakt, moeten makkelijk kunnen aangepast worden, zonder dat dit een impact heeft op andere, bestaande of toekomstige delen van het softwaresysteem. 4. Als door het toebrengen van een slag, de aangebrachte schade groter is dan het aantal raakpunten van het betrokken monster, zal de held bij het toebrengen van die genadeslag enigszins herstellen van de opgelopen schade, en potentieel zijn bezittingen uitbreiden met bezittingen van het stervend monster. Beide aspecten worden hieronder toegelicht. Alle wapens en harnassen die het verslagen monster met zich mee droeg, en die achterblijven na het toebrengen van de genadeslag vernietigen zich zelf; rugzakken, geldbeugels en goudstukken die niet meegenomen worden, blijven achter op de grond. 6.7 Genezen [Heal] Zoals hierboven reeds werd aangegeven, kunnen helden herstellen bij het toebrengen van de genadeslag aan een monster. Concreet wordt bij het herstellen een willekeurig percentage berekend. De raakpunten van de held worden vervolgens verhoogd met het gegenereerde percentage van het verschil tussen de maximale raakpunten van de held en zijn huidige raakpunten. 6.8 Schattenrapen [Collect treasures] Zoals hierboven reeds werd aangegeven, kunnen helden bij het toebrengen van de genadeslag aan een monster diens bezittingen overnemen. Op dit vlak moeten alle mogelijke opties open zijn, gaande van het achterlaten van alle bezittingen van het stervend monster tot het overnemen van al diens bezittingen. Je mag hier vrij een concreet algoritme uitwerken. Als je streeft naar een score van 80% of meer voor het project, moet het algoritme een minimale vorm van intelligentie bij helden weerspiegelen. 13

14 7 Monsters [Monsters] Monsters zijn de vijanden van helden. Ze zullen helden dan ook aanvallen. Monsters hebben geen intelligentie. Ze zullen daarom ook onderling vechten. Een monster wordt gekenmerkt door volgende eigenschappen. 7.1 Naam [Name] Monsters hebben steeds een naam. In de huidige versie van het spel voldoen namen van monsters aan precies dezelfde regels als die voor namen van helden. Destroyer o Hope is een voorbeeld van een geldige naam voor een monster. Ook hier geldt dat in toekomstige versies van het spel enkel bijkomende tekens zullen worden toegelaten. Daarbij is het wel mogelijk dat de spellingsregels voor monsters en helden uit mekaar groeien. 7.2 Ankers [Anchors] Monsters hebben, net zoals helden, een aantal ankerpunten waarmee ze allerlei spullen met zich mee kunnen dragen. Het aantal ankerpunten voor monsters kan verschillen van monster tot monster. Monsters zonder enig ankerpunt behoren ook tot de mogelijkheden. Zoals bij helden, kan elk ankerpunt van een monster gebruikt worden om precies één wapen, één harnas, één rugzak, één geldbeugel of één dukaat mee te nemen. Bij zijn geboorte zal ieder monster potentieel voorzien worden van een element voor ieder van zijn ankerpunten. Concreet moeten alle elementen die een nieuw monster met zich moet meesleuren, meegegeven worden bij constructie van het monster. Deze elementen zullen willekeurig verspreid worden over de ankerpunten van het nieuwe monster. De draagcapaciteit van het nieuwe monster zal zodanig worden gekozen, dat het minstens alle meegegeven spullen kan dragen. 7.3 Schade [Damage] Monsters gebruiken klauwen, tanden of andere lichaamsdelen om te vechten. Monsters zijn niet intelligent genoeg om wapens te hanteren. Elk monster wordt gekenmerkt door de schade die het kan aanrichten bij de tegenstander in een gevecht. Hiervoor gelden dezelfde bepalingen als voor de schade die wapens kunnen aanrichten bij tegenstanders. 14

15 7.4 Beschermingsfactor [Protection] Monsters hebben een taaie, dikke of geschubde huid, die als een natuurlijk harnas fungeert. Monsters zijn niet intelligent genoeg om (andere) harnassen aan te trekken. Voor de beschermingsfactor inherent aan een monster gelden dezelfde bepalingen als voor de beschermingsfactor die harnassen bieden. 7.5 Raakpunten [Hitpoints] Elk monster heeft, net zoals elke held, een beperkt aantal raakpunten. Hiervoor gelden dezelfde bepalingen als voor raakpunten van helden, met die uitzondering dat de raakpunten van monsters niet verhogen op het einde van een gevecht dat ze als winnaar afgesloten hebben. 7.6 Kracht [Strength] Elk monster heeft ook ten alle tijde een indicatie van zijn kracht. Hiervoor gelden dezelfde bepalingen als voor de kracht van helden. Zoals bij monsters bepaalt de kracht van een monster ook zijn draagcapaciteit. Monsters zonder kracht kunnen niets met zich meedragen. Voor monsters met een positieve kracht is de draagcapaciteit steeds gelijk aan de kracht van het monster vermenigvuldigd met 12 kg. 7.7 Slaan [Hit] Monsters kunnen vechten tegen andere monsters en tegen helden. Ze doen dit door de tegenstander herhaaldelijk te slaan. Zoals voor helden, moet in de context van dit project enkel het toebrengen van één slag door een monster aan zijn tegenstander worden uitgewerkt. Het toebrengen van een slag door een monster verloopt als volgt: 1. Er wordt op één of andere manier een getal gegenereerd tussen 0 en 30. Indien dit getal lager ligt dan de huidige raakpunten van het monster, wordt met dit getal verder gewerkt. Anders wordt gewerkt met de huidige raakpunten van het monster. 2. Het resulterende getal wordt vergeleken met de beschermingsfactor van de tegenstander. Als het resulterende getal groter is dan of gelijk aan de beschermingsfactor van de tegenstander, dan is er raak geslagen. In het andere geval heeft de slag geen impact. 3. In het geval van een rake slag worden de raakpunten van de tegenstander verminderd met de schade die de slag bij hem teweeg brengt. In de huidige versie van het spel, is de schade die een slag veroorzaakt de som van 2 15

16 getallen. Het eerste getal is de schade die het monster kan aanrichten bij zijn tegenstander. Het tweede getal wordt bepaald door de kracht van het monster. Dit getal wordt bekomen door de kracht van het betrokken monster te verminderen met 5, en vervolgens te delen door 3, waarbij cijfers na de komma worden weggelaten. 4. Als door het toebrengen van een slag, de aangebrachte schade groter is dan het aantal raakpunten van de tegenstander, zal het monster bij het toebrengen van die genadeslag potentieel zijn bezittingen uitbreiden met bezittingen van de stervende tegenstander. Dit wordt hieronder verder toegelicht. Merk op dat monsters nooit kunnen herstellen van opgelopen verwondingen. Alle wapens en harnassen die de verslagen tegenstander met zich mee droeg, en die achterblijven na het toebrengen van de genadeslag vernietigen zich zelf; rugzakken, geldbeugels en goudstukken die niet meegenomen worden, blijven achter op de grond. 7.8 Schattenrapen [Collect treasures] Monsters zijn wezens zonder enige vorm van intelligentie. Zij kunnen dan ook geen inschatting geven van de waarde of het nut van diverse soorten dingen. Monsters voelen zich wel sterk aangetrokken tot alles wat blinkt. Daarom zullen ze geneigd zijn eerder losse dukaten en geldbeurzen over te nemen van een stervende tegenstander, dan wapens of harnassen. Niets sluit echter uit dat ze andere dingen meenemen, of dat ze zelfs dingen die ze momenteel meesleuren wisselen voor dingen die gedragen worden door de stervende tengestander. Zo kan het bijvoorbeeld zijn dat ze een geldbeugel dukaten inruilen voor een waardeloos harnas. 8 Genezende Drankjes [Healing Potions] De elementen die hier beschreven worden, moeten niet worden uitgewerkt door studenten die het project alleen maken. Naast wapens, dukaten,... kunnen helden en monsters vanaf nu ook in het bezit zijn van genezende drankjes. Bij helden herstelt het innemen van een genezend drankje een deel van de mogelijke schade die opgelopen werd in een gevecht. Monsters kunnen ook genezende drankjes innemen, maar bij hen hebben ze geen uitwerking. Een genezend drankje heeft de volgende kenmerken: 16

17 8.1 Identificatie [Identification] Elk drankje heeft een identificatie in de vorm van een groot geheel getal (type long in Java). Het identificatienummer van een drankje zal steeds een positief getal zijn, dat na de produktie van het drankje niet meer kan veranderen. Binnen hetzelfde spel kunnen nooit twee verschillende drankjes voorkomen net een zelfde identificatienummer. Er kunnen wel andere soorten dingen in omloop zijn, waarvan het identificatienummer gelijk is aan dat van een drankje. 8.2 Gewicht [Weight] Elk drankje heeft een gewicht. Het gewicht van een drankje dat nog niet werd ingenomen door een held of een monster, is gelijk aan het initiële gewicht van het drankje. Voor het initiële gewicht van drankjes gelden dezelfde bepalingen als voor het gewicht van wapens.van zodra een drankje werd ingenomen door een held of een monster, blijft alleen het flesje over. Het gewicht daarvan is steeds 100 gram. 8.3 Waarde [Value] Elk drankje heeft een waarde. De waarde van een drankje dat nog niet werd ingenomen door een held of een monster, is gelijk aan de eigen waarde van het drankje. Voor de eigen waarde van een drankje gelden dezelfde bepalingen als voor de eigen waarde van een rugzak. Van zodra een drankje werd ingenomen is het niets meer waard. 8.4 Raakpunten [Hitpoints] Elk drankje heeft een beperkt aantal raakpunten. Hiervoor gelden dezelfde bepalingen als voor raakpunten van helden en monsters. De raakpunten van een drankje veranderen niet zolang het drankje niet ingenomen wordt. Van zodra een drankje ingenomen werd door een held of een monster, worden de raakpunten van het drankje teruggebracht tot 0. Indien het drankje wordt ingenomen door een held, worden de raakpunten van die held verhoogd met de raakpunten van het ingenomen drankje. Daarbij kan het maximaal aantal raakpunten nooit worden overschreden. Indien het drankje ingenomen wordt door een monster, heeft het geen effect. 8.5 Slaan [Hit] In de context van een gevecht zullen helden op een intelligente manier proberen om te gaan met hun drankjes. Monsters zullen tijdens een gevecht nooit een genezend drankje innemen. In plaats van hun tegenstander proberen te slaan, zullen helden 17

18 ten gepaste tijde beslissen een genezend drankje in te nemen. Hiervoor gelden de volgende regels: 1. Zolang helden nog minstens 40% van hun maximaal aantal raakpunten hebben, zullen ze de voorkeur geven aan het toebrengen van een slag. 2. Wanneer de raakpunten van een held gedaald zijn tot een waarde die ligt tussen 20% en 40% van hun maximum aantal raakpunten, zullen ze er de voorkeur aan geven om een genezend drankje in te nemen. Voorwaarde hiervoor is uiteraard dat de held minstens één drankje met zich mee draagt, en dat hij maximaal profiteert van het effect van het in te nemen drankje (i.e. de raakpunten van het betrokken drankje mogen niet hoger zijn dan het aantal verloren raakpunten van de betrokken held). Wanneer een held meerdere drankjes ter beschikking heeft die aan de gestelde voorwaarden voldoen, zal hij het drankje met de grootst mogelijke werking innemen. Wanneer hij geen dergelijk drankje ter beschilkking heeft, zal hij zijn tegenstander proberen te slaan. 3. Zodra de raakpunten van een held beneden de 20% van het maximim komen te liggen, begint de held te panikeren. Indien hij drankjes ter beschikking heeft, zal hij er steeds de voorkeur aan geven om een drankje in te nemen in plaats van te slaan naar zijn tegenstander. Omdat hij niet meer helder van geest is, zal hij in dat geval willekeurig één van de drankjes nemen die hij met zich mee draagt. 8.6 Schattenrapen [Collect treasures] Bij het schattenrapen zullen helden en monsters nu ook de mogelijkheid hebben om drankjes over te nemen van hun stervende tegenstander. Als je streeft naar een score van 80% of meer voor het project, moet het algoritme voor helden ook voor drankjes getuigen van een zekere vorm van intelligentie bij helden. 9 Hoofdprogramma De werking van alle ontwikkelde klassen moet je kunnen demonstreren aan de hand van volgend voorbeeld: 1. Construeer een held, gebruik makend van één van de constructoren die je daarvoor gebouwd hebt. Schrijf de totale waarde van alle bezittingen van de nieuwe held uit op de standaard uitvoerstroom. 18

19 2. Construeer een monster, gebruik makend van één van de constructoren die je daarvoor gebouwd hebt. Schrijf de totale waarde van alle bezittingen van het nieuwe monster uit op de standaard uitvoerstroom. 3. Werk een gevecht uit tussen de held en het monster, waarbij ze mekaar om beurt proberen te slaan. Laat één van beiden willekeurig beginnen. Het gevecht wordt voortgezet tot één van beiden sterft. Ook het eventuele herstellen van opgelopen verwondingen (voor helden) en het schattenrapen moeten geactiveerd worden. 4. Schrijf na afloop van het gevecht uit wie de winnaar is, en wat de totale waarde is van al zijn bezittingen (na het schattenrapen). Je mag altijd meer informatie uitschrijven op de standaarduitvoerstroom, mocht je dat nodig vinden. In geen geval mogen er zich schrijfopdrachten bevinden buiten de klasse waarin dit hoofdprogramma zich bevindt. 10 Praktische Richtlijnen We verwachten dat dit project volledig kan afgewerkt worden in 30 uur. Hierbij veronderstellen we dat de materie die aan bod komt in de cursus, vooraf volledig verwerkt is. Daarenboven kan het project enkel binnen die tijdsspanne worden uitgewerkt, indien je op een beredeneerde en gedisciplineerde manier te werk gaat. We raden sterk aan om de principes van Extreme Programming zoveel mogelijk toe te passen bij de uitwerking van het project Verdere richtlijnen rond de oplossing 1. Enkel de expliciet opgelegde vereisten moeten voorzien worden. Je zal geen indruk maken door bijkomende spelelementen te voorzien in je oplossing. 2. Hoewel de opgave vrij uitgebreid is, hebben we niet gepoogd alle mogelijke details in te vullen. Alles wat niet uitdrukkelijk vermeld is in de opgave mag je dan ook naar eigen inspiratie invullen. Kies daarbij steeds voor de gemakkelijkste oplossing. 3. Dit project moet uitgewerkt worden in Java 5 of hoger. 4. Er moeten geen lus-invarianten noch lus-varianten worden uitgewerkt. 5. Als opgelegd wordt dat methodes rond een bepaalde karakteristiek nominaal, totaal of defensief moeten uitgewerkt worden, geldt dit ook voor het 19

20 manipuleren van die karakteristieken in meer complexe methodes (vb. constructoren). 6. Naast constructie, moet voor wapens, harnassen, rugzakken, geldbeugels, helden en monsters ook terminatie expliciet ondersteund worden. 7. Voor rugzakken en geldbeugels moeten iteratoren aangeboden worden, waarmee element per element door hun inhoud kan gegaan worden. Ook voor helden en monsters moeten iteratoren voorzien worden waarmee element per element kan gegaan worden over alle dingen die potentieel vast zitten aan hun ankerpunten. Al deze iteratoren moeten de interface Iterator uit de standaard Java API implementeren. 8. Tenzij uitdrukkelijk anders vermeld wordt in de opgave, moeten alle aspecten van de ontwikkelde klassen zowel formeel als informeel worden gespecificeerd. 9. Inspectoren die één of andere som als resultaat teruggeven, moeten niet formeel gespecificeerd worden. Je mag verder aannemen dat het aantal elementen in rugzakken en geldbeugels, alsook het aantal ankerpunten van helden en monsters klein genoeg is, waardoor het altijd kan uitgedrukt worden als een int. 10. Het spreekt voor zich dat we sterk aanraden om zoveel mogelijk methodes te testen. Samen met de definitie van de klassen moet je in ieder geval de nodige testen voorzien voor de methode om de inhoud van een geldbeurs over te brengen naar een andere geldbeurs. We vragen geen documentatie voor testklassen. 11. Naast de specificatie en implementatie van de gevraagde klassen, moet ook een schets van het ontwerp worden gemaakt. Deze bevat alle ontwikkelde klassen en interfaces, behalve zelfgedefinieerde uitzonderingsklassen en testklassen. Het ontwerp moet uitgetekend worden in UML. Voor interfaces moet enkel de naam worden opgenomen in de tekening; voor klassen moet de naam worden opgenomen, samen met alle attributen die in die klasse aanwezig zijn. De ontwerptekening mag geen opsomming bevatten van methodes Inleveren 1. Het project moet ingediend worden vóór donderdag 1 juni om 9.00 uur. Afwijkingen op dit tijdstip zullen slechts in zeer uitzonderlijke gevallen worden 20

21 toegestaan. Uitstel tot 15 juni om 9.00 uur is momenteel toegestaan aan alle studenten, die dit academiejaar een eindwerk moeten verdedigen. Studenten die hun project reeds komen verdedigen op 1 juni, moeten ingeleverd hebben voor woensdag 30 mei om uur. 2. Het indienen gebeurt via Toledo. Dien je oplossing als JAR-bestand in. Je kan met de Eclipse omgeving eenvoudig het JAR-bestand genereren met de export functie die je o.a. in het file menu vindt. Let erop dat je al je ontwikkelde klassen selecteert (Select the resources to export), en neem zowel de.java source files als de gegenereerde.class files op! Vermeld je naam en studierichting in commentaar bij het indienen. Bij het indienen moet je bevestigen tot je oplossing effectief werd ingeleverd! 3. De ontwerptekening moet niet elektronisch worden ingeleverd. Ze moet enkel op papier worden meegenomen naar de verdeging Verdediging 1. Het project moet mondeling verdedigd worden bij prof. Eric Steegmans. De verdedigingen starten op 1 juni. Op Toledo zal rond 20 mei een lijst verschijnen met mogelijke data waarop het project kan verdedigd worden. Een concrete afspraak voor je verdediging zal je vanaf dan kunnen aanvragen via naar prof. Steegmans. Meer informatie hierover volgt later op Toledo. 2. Je moet je project verdedigd hebben ten laatste 2 werkdagen voor je deliberatie. Als je deliberatie bijvoorbeeld plaats heeft op vrijdag 30 juni, dan kan je ten laatste verdedigen op dinsdag 27 juni. Vind je deliberatie bijvoorbeeld plaats op dinsdag 4 juli, dan kan je ten laatste verdedigen op donderdag 30 juni. 3. Je moet de ontwerptekening in UML op papier meebrengen naar de verdediging. Zonder deze ontwerptekening kan de verdediging niet doorgaan! Vermeld duidelijk je naam en studierichting op deze schets. Mocht deze opgave op bepaalde punten onduidelijk zijn, zal verdere toelichting gegeven worden via Toledo. Om tegenstrijdigheden in antwoorden te vermijden, kunnen vragen uitsluitend gestuurd worden naar: [email protected] Veel succes! 21