bug fixen F. Vonk versie

Transcriptie

1 2017 bug fixen F. Vonk versie

2 inhoudsopgave 1. inleiding bug fixen Sokoban Breakout Pac-Man Asteroids Snake Super Mario Dit werk is gelicenseerd onder een Creative Commons Naamsvermelding NietCommercieel GelijkDelen 3.0 Unported licentie De afbeelding op het voorblad is verkregen via INFOwrs. Copyright 2010 INFOwrs Serviços em informatica

3 1. inleiding Om software te kunnen maken moet je onder andere snappen hoe je software bugs (software fouten) moet fixen (oplossen). In deze module ga je oefenen met het fixen van bugs. Welkom bij de module bug fixen. Je gaat in deze module een zestal games afmaken door middel van bug fixen. Je krijgt een beginsituatie van een spel met daarin ontbrekende functionaliteit. Vervolgens ga je de functionaliteit zelf toevoegen, dat is een vorm van bug fixen. In deze module kom je opgaves tegen die je moet maken om de lesstof te verwerken. De antwoorden kunnen in de les besproken worden. opgave Opgaves in blauw moet je maken. Let op, links in dit document hebben een rode kleur. Veel plezier en succes

4 2. bug fixen Bugs zijn, simpel gezegd, fouten in de software. Een fout kan ontstaan door foute code, maar ook door ontbrekende, overbodige of overtollige code. Het vinden en verwijderen van een bug uit een stuk software noemen we bug fixen. In de volgende hoofdstukken krijg je te maken met fouten veroorzaakt door ontbrekende code. Je krijgt ook een handleiding, via gm.michelfiege.nl, die beschrijft welke code je toe moet voegen en waarom. Je krijgt dus een handleiding voor het bug fixen. Tijdens het bug fixen maak je ongetwijfeld af en toe zelf een fout. Daarmee introduceer je zelf een nieuwe bug en deze moet je natuurlijk weer oplossen. Van de oefeningen in de volgende hoofdstukken wordt je geacht te leren hoe GameMaker werkt en hoe bepaalde concepten in GameMaker werken. Zorg daarom dat je niet blindelings de handleiding volgt, maar dat je ook begrijpt waarom je dingen doet! In het SE over bug fixen word je geacht fouten op te kunnen lossen die je vindt in de games die je voorgeschoteld krijgt zonder handleiding! - 4 -

5 3. Sokoban Sokoban is een bekend puzzelspel uit Het is bedacht door Hiroyuki Imabayashi. Voor meer informatie kun je kijken op Wikipedia. In de game wereld wordt ook de afkorting PC gebruikt. Dit staat niet voor Personal Computer, maar voor Player Character. Hiermee wordt het poppetje in het spel bedoeld, dat door de speler bediend wordt. In een spel kunnen ook poppetjes voorkomen, die niet door de speler worden bediend, maar door de computer. Zo'n poppetje noemen we een NPC (Non Player Character). Zoals gezegd, wordt een NPC dus door de computer bediend. Dat wil zeggen dat iemand software geschreven heeft die het gedrag van de NPC definieert. Dit wordt in de game wereld vaak AI (Artificial Intelligence, Kunstmatige Intelligentie) 1 genoemd. Een betere term zou echter Kunstmatig Gedrag (Artificial Behavior) zijn. opgave 3.1 Ga naar de website van Michel Fiege en kies het eerste spel, dat is Sokoban. Ga dit spel maken met behulp van GameMaker. Je kunt op school het stuk over "Game Maker 8 downloaden en installeren" overslaan en verder gaan bij "Game Maker opstarten". Zet "advanced mode" aan! Je kunt GameMaker 8.1 opstarten via het Windows Start Menu. Het staat onder vakken informatica. Nu je je eerste spel hebt gemaakt, heb je hopelijk gemerkt dat een spel aan veel producteisen voldoet. Producteisen zijn eisen die specifiek over het product gaan, in dit geval over Sokoban. Naast producteisen bestaan er ook nog andere soorten eisen zoals project- en proceseisen. De producteisen van Sokoban worden niet expliciet gemaakt door meneer Fiege, maar dat zou eigenlijk wel moeten. Hoe weet je anders wat een bug is en wat niet? Daarom hebben we de producteisen voor Sokoban en de andere games voor je opgeschreven. 1 In het algemeen beschouwen informatici het programmeren van geautomatiseerde tegenstanders in een spel niet als kunstmatige intelligentie! - 5 -

6 Je vindt de producteisen van alle spellen bij deze module in de ELO. Op het SE krijg je natuurlijk de producteisen voor de games waarin je bugs moet fixen erbij. Die moet je natuurlijk niet helemaal doorlezen op het SE, want dan kom je in tijdnood. Gebruik ze als je twijfelt over welk gedrag je moet verwachten. Tijdens het maken van Sokoban heb je hopelijk zelf af en toe ook een foutje gemaakt. Hopelijk heb je ook gemerkt dat het vinden van fouten lang kan duren. Bedenk daarnaast dat je na het bug fixen ook moet controleren of je de fout goed hebt opgelost. Wanneer dat controleren net zo lang duurt als het vinden van de fout, dan is dat niet handig. Op het SE heb je immers maar beperkt de tijd. Om tijd te besparen bij het vinden van fouten en controleren of een fout is opgelost is het vaak handig om je speelveld aan te passen. Je maakt dan als het ware een test speelveld (of test level). Door bijvoorbeeld je PC op een handige plaats neer te zetten kun je soms veel tijd besparen. Om bijvoorbeeld te controleren of je correct naar het volgende level gaat bij Sokoban, zou je het eerste speelveld kunnen veranderen zodat je maar 1 stip en 1 doos hebt. Als je de PC, de doos en de stip dan ook nog eens naast elkaar zet, dan kost het nauwelijks tijd om de level overgang te testen

7 Naast het bug fixen heb je bij dit spel ook een belangrijke programmeerconcept geleerd: de variabele. opgave 3.2 Beschrijf in je eigen woorden wat een variabele is. 4. Breakout Breakout is een bekend tennisspelletje uit 1976, dat geïnspireerd is op het nog oudere Pong. Voor meer informatie kun je kijken op Wikipedia. opgave 4.1 Ga naar de handleiding voor het Breakout spel op de website van Michel Fiege. Ga dit spel maken met behulp van GameMaker. Zorg ook dat je oefent met het aanpassen van speelvelden (maken van test speelvelden) om sneller fouten te vinden en te controleren of je dingen goed opgelost hebt! Naast het bug fixen heb je bij dit spel ook een aantal belangrijke programmeerconcepten geleerd. Te weten: verschil tussen object en instantie (instance) overerving (inheritance) functie globale versus lokale variabele opgave 4.2 Beschrijf in je eigen woorden de bovenstaande vier programmeerconcepten

8 5. Pac-Man Pac-Man is één van de bekendste spellen ter wereld. Het werd in 1980 gemaakt, veroverde de hele wereld en wordt nog steeds gespeeld. Voor meer informatie kun je kijken op Wikipedia. opgave 5.1 Ga naar de handleiding voor het Pac-Man spel op de website van Michel Fiege. Ga dit spel weer maken met behulp van GameMaker. Zorg ook dat je oefent met het aanpassen van speelvelden (maken van test speelvelden) om sneller fouten te vinden en te controleren of je dingen goed opgelost hebt! Naast het bug fixen heb je bij dit spel ook een belangrijke programmeerconcept geleerd: recursie. opgave 5.2 Beschrijf in je eigen woorden wat recursie is

9 6. Asteroids opgave 6.1 Ga naar de handleiding voor het Asteroids spel op de website van Michel Fiege. Ga dit spel weer maken met behulp van GameMaker. Zorg ook dat je oefent met het aanpassen van speelvelden (maken van test speelvelden) om sneller fouten te vinden en te controleren of je dingen goed opgelost hebt! Naast het bug fixen heb je bij dit spel ook een belangrijke programmeerconcept geleerd: modulo rekenen. opgave 6.2 Beschrijf in je eigen woorden wat modulo rekenen is

10 7. Snake opgave 7.1 Ga naar de handleiding voor het Snake spel op de website van Michel Fiege. Ga dit spel weer maken met behulp van GameMaker. Let op: Om de status balk bovenin het scherm te zien moet je eerst een wijziging in de code maken. Doorloop de volgende stappen: 1. Open het object obj_controller. 2. Ga naar het Draw event. 3. Verwijder de eerste actie: Set font to font_courier. Zorg ook dat je oefent met het aanpassen van speelvelden (maken van test speelvelden) om sneller fouten te vinden en te controleren of je dingen goed opgelost hebt! Naast het bug fixen heb je bij dit spel ook twee belangrijke GameMaker concepten geleerd: room_speed en het assenstelsel van GameMaker. opgave 7.2 Beschrijf in je eigen woorden de bovenstaande twee GameMaker concepten

11 8. Super Mario Super Mario is ook één van de bekendste spellen ter wereld. Het is een spel dat op veel verschillende soorten spelcomputers uit is gebracht en waar veel vervolgen op gemaakt zijn. Ook dit is een spel dat nog steeds gespeeld wordt. Voor meer informatie kun je kijken op Wikipedia. Tijdens het maken van dit spel ga je een ontwerptechniek (modelleringstechniek) tegenkomen die gebruik maakt van toestandsdiagrammen. Dit zijn diagrammen met daarin toestanden en toestandsovergangen. Een toestandsdiagram kan bij één object uit het spel horen, maar ook bij meerdere. De toestanden geven aan in welke stationaire situatie zich een object of objecten kunnen bevinden. Een stationaire situatie is een situatie die relatief lang duurt; de speler kan deze situatie herkennen als hij/zij speelt. De toestandsovergangen geven aan hoe je van de ene toestand in de andere komt. Toestandsovergangen zijn meestal instantaan, dat wil zeggen dat ze geen tijd in beslag nemen of relatief kort duren. De speler ziet wel dat een toestandsovergang plaats heeft gevonden, maar de overgang zelf gaat zo snel dat de speler er de details niet van ziet. Toestandsovergangen worden getriggerd door events; dat wil zeggen, dat een toestandsovergang gebeurt wanneer een bepaald even optreedt tijdens het spelen van het spel. opgave 8.1 Ga naar de handleiding voor het Pac-Man spel op de website van Michel Fiege. Ga dit spel weer maken met behulp van GameMaker. Zorg dat je tijdens het maken goed snapt hoe de toestandsdiagrammen in de uitleg werken en hoe ze tot stand komen. Het eerste toestandsdiagram, dat je tegenkomt is dat van Koopa de schildpad. Dit toestandsdiagram zie je in Figuur 1. Je ziet in Figuur 1 drie toestanden voor het object obj_koopa. De bovenste toestand is meestal de begintoestand (al zou dit officieel aangegeven moeten worden met een overgang vanuit een zogenaamd begintoestandssymbool). De pijlen geven aan door welk event (of soms ook events) er over wordt gegaan naar een nieuwe toestand. Je ziet bijvoorbeeld, dat een instantie van het object bij het event botsing met obj_mario_air vanuit de toestand obj_koopa (lopend) naar toestand obj_koopa_hit (stil liggend) gaat. Let op, dat het event botsing met

12 obj_mario (parent) betekent, dat een botsing met een child (kind) instantie het event ook laat gebeuren. Dit heeft te maken met de regels voor overerving (inheritance) die je zou moeten kennen uit het spel Breakout. Figuur 1: Toestandsdiagram voor obj_koopa. Iedere instantie (instance) van het object obj_koopa heeft een eigen versie van het toestandsdiagram van het object. Iedere instantie kan zich daarom in een andere toestand bevinden als je het spel speelt. Het is dus niet zo, dat als Mario botst met de ene instantie van obj_koopa dat een andere instantie ook van toestand verandert. opgave 8.2 Bekijk de code van het spel goed en zoek uit waar het toestandsdiagram in de code verwerkt (geïmplementeerd) is. Zorg dat je goed snapt wat er gebeurt en hoe het toestandsdiagram in elkaar steekt. Naast het bug fixen heb je bij dit spel ook een belangrijk ontwerpconcept geleerd: toestandsdiagrammen. opgave 8.3 Beschrijf in je eigen woorden wat toestandsdiagrammen zijn