Laboration 2 - Hoppsansa

I den här labben ska du göra ett knepigt spel för att träna mer på komponenter, inre klasser, layouter, lyssnare och designmönstret Model-View-Control. Spelet heter Hoppsansa och ser ut så här. Det finns tre gröna pjäser (knappar) till höger, tre röda till vänster och en tom plats i mitten. Man flyttar omväxlande gröna och röda. I varje drag får en pjäs flytta till den tomma rutan om den är alldeles intill eller det finns precis en motståndare mellan pjäsen och den tomma rutan. Först skrivs en textbaserad version av spelet och därefter den grafiska. Programmet (programmen) ska hålla reda på vems tur det är och inte tillåta två drag i rad av samma färg. I grunduppgiften krävs inte att något meddelande skrivs om man försöker göra ett otillåtet drag.

För att få godkänt på labben måste man ha lyckats byta plats på dom gröna och dom röda enligt spelets regler!

Spellogiken i Model

Spellogiken ska läggas i en egen klass. Klassen ska ha åtminstone dessa två metoder som är de väsentliga för spelet:

 move(k) // flyttar pjäsen på plats k till tomma platsen om det är tillåtet
 get(k)  // returnerar innehållet (dvs färgen) på plats k

Ni får införa fler metoder om ni tycker att det behövs. Hur spelets pjäser och tom ruta ska representeras får ni bestämma själva men 0, 1 och 2 är naturliga val. Information om vems tur det är måste också finnas. Det är listigt när man skriver Model att ha en variabel tom som anger index för den tomma rutan. Tänk igenom spellogiken noga så att klassen Model blir både kort och tydlig! Observera att själva spelandet inte utförs i Spellogiksklassen. Klassen tillhandahåller metoder för att uföra spelets drag och spelandet görs av andra programdelar. Spellogiken utgör Model i Model-View-Control-mönstret och i uppgiften ingår att skriva program som spelar spelet med två olika View-Control-delar, en textbaserad och en grafisk.

Textversionen av spelet.

Så här kan det se ut när man spelar:

  GGG RRR   Välj 0-6: 2
  GG GRRR   Välj 0-6: 4
  GGRG RR   Välj 0-6:

Det texbaserade spelet kan man skriva i en egen klass eller lägga det i en main-metod i Model-klassen. Spelet spelas genom att man anropar metoder ur Model-klassen. Vi kan se det textbaserade spelet som en test av Model-klassens funktionalitet innan vi använder Model i vårt grafiska program.

Tillägg 14 april: Inläsning av text från terminalfönstret görs enklast med klassen Scanner som finns i paketet java.util. Klicka här för ett exempel på hur man använder Scanner: HejMedFragor.java.

En grafisk komponent med en inre knappklass

I den grafiska versionen av spelet måste man ha klickbara rutor som kan ändra färg. Använd en utökad version av JButton (jfr labb1) som heter t.ex. Ruta och ges en metod för att sätta knappens färg till grön, röd eller vit (för tom ruta), t.ex. så här:

   ruta[i].set(0); //Knappen blir vit
   ruta[i].set(1); //Knappen blir grön
   ruta[i].set(2); //Knappen blir röd

Ruta skrivs bekvämast som en inre klass i den större grafiska komponentklass som utgör spelet. Lyssnare av typen ActionListener behövs för att detektera knapptryckningarna. Lyssnaren kan vara en yttre klass, en inre klass, en anonym klass eller en redan existerande containerklass. Skall man ha en enda lyssnare som lyssnar på alla knapparna eller ska varje knapp ha en egen lyssnare? Välj själva! En lösning där programmet måste gå igenom alla knapparna för att hitta vilken man tryckt på godtas inte! Efter en knapptryckning ska programmet direkt "veta" vilken knapp det var och vilket nummer den har (för vidare befordran till Model-objektet). getSource() i klassen ActionEvent är användbar.

Välj själv om View-Control-delen av programmet ska skrivas som en applet eller ett fristående program.

Redovisning

Vid redovisning så skall följande visas upp och förklaras

En spelbar textversion av spelet med en klass för spellogiken enligt ovan. En lösning utan Model-klass, där t.ex. allt i spelet sköts i en main-metod godkänns ej.
En spelbar grafisk version av spelet som använder samma klass för spellogiken som textversionen gör och som har en tydlig uppdelning på Model och View-Control.
Visa att ni förstår Model-View-Control-strukturen och hur den tillämpas i uppgiften.
Dessutom ska ett UML-klassdiagram över den grafiska grunduppgiften visas och förklaras, enligt checklistan för labbredovisningar som återfinns här: Labbredovisning.html

Extrauppgift 1:

Låt det vara grodor som hoppar åt höger och pingviner som hoppar åt vänster i den grafiska versionen av programmet. Spelet med rött och grönt ska redovisas först och får inte erstättas med bildversionen. Det går förstås bra med egna bilder istället för grodor och pingviner! Högerklicka på bilderna nedan om du vill spara dem till det egna programmet!

Extrauppgift 2:

Utvidga programmet så att ett meddelande ges efter varje drag eller försök till drag. Användaren ska få veta om draget var OK eller fel. Om det var fel så meddelas vilken sorts fel det var. Se till att det är Modell-klassen som avgör vilket meddelande som ska ges. View-delen av programmet måste förstås presentera meddelandet för användaren. Den här extrauppgiften får man ta med i sitt program från början om man vill.

Alternativuppgift:

Gör ett femtonspel eller luffarschack (3x3 eller större) enligt samma princip som Hoppsansa-spelet, dvs med en Model-klass för logiken och en textbaserad VC-klass samt en grafisk VC. Den här uppgiften är ju lite större så den inkluderar direkt godkänt på Extrauppgift 1. Extrauppgift 2 är samma som för Hoppsansa.

Glöm inte att be om handledarens underskrift på ditt kvittensblad när du är godkänd! Kvittensbladet finns för utskrift på kurshemsidan under Laborationer.

Sidansvarig: <ann@nada.kth.se>
Senast ändrad 17 mars 2010
Tekniskt stöd: <webmaster@nada.kth.se>