Om du vill sätter du nu upp ett nytt IDEA-projekt för Tetris-labben. Det går också bra att fortsätta i det gamla projektet, så länge du separerar de gamla och nya klasserna från varandra genom att lägga dem i olika (under)paket.

Nu ska vi börja tänka genom alternativ för modellering. Läs genom hela rutan innan du börjar genomföra detta.

Hur representerar vi spelplanens nuvarande "utseende"? Vi kunde tänka oss att spelplanen (Board) skulle lagra en lista av de hela tetrisblock som har ramlat ner samt x- och y-positioner för dessa block på planen. Men när ett tetrisblock väl har "fallit på plats" kan vissa av dess kvadrater så småningom försvinna medan andra finns kvar (att fulla rader försvinner är ju själva poängen med spelet). Detta vore det rätt krångligt att representera med en lista över tetrisblock eftersom vi skulle behöva hålla reda på vilka delar av varje tetrisblock som fortfarande finns kvar.

Istället kan vi modellera på följande sätt: För varje position (x,y) på spelplanen, är den tom, och om inte, vilken typ av tetromino tillhör kvadraten på den positionen? Varje gång ett block faller på plats läggs det då in information om fyra nya kvadrater på lämpliga koordinater i Board-objektet. Vi behöver inte hålla reda på vilket tetrisblock varje enskild kvadrat kom från, och vi behöver inte ens separata objekt för varje kvadrat -- bara separata objekt för varje kvadrattyp.

Hur representerar vi då en "typ av kvadrat"? Vi vill kunna representera exakt 8 olika värden: "här finns ingen kvadrat", "här finns en kvadrat från ett I-block", "här finns en kvadrat från ett T-block", och så vidare. Java stödjer enum-klasser, som är gjorda just för situationen när en klass har ett fast antal värden. ("Enum" kommer från "enumeration", dvs. "uppräkning". Vi vill räkna upp de 8 värden som finns, och sedan ska man inte kunna skapa nya.)

Vi ska därför skapa en enum-typ med namn SquareType. Eftersom vi troligen inte har hunnit fram till enums i föreläsningarna än, ger vi lite extra hjälp nedan.

En SquareType ska bara indikera vilken typ av tetromino som har resulterat i en viss kvadrat på skärmen. Den ska däremot inte ha några metoder för att faktiskt rita upp en kvadrat till exempel i en viss färg. Den bestämmer inte heller vilken färg kvadraten ska ha, eller om kvadraten ska visualiseras "platt" eller i pseudo-3D som i exemplet ovan (eller med en riktig 3D-motor där man kan rotera spelplanen), och så vidare. SquareType är ju enbart en del av modellen.

En vy kommer vi att skapa senare, och då är vi till och med fria att visualisera i textformat om vi vill, genom att konvertera varje enumkonstant (som det inte finns särskilt många av) som ett specialtecken som "#" eller "%". Inom schack skulle "pjäsmodellen" inte heller innehålla information om hur en kung skulle se ut på skärmen, men det kan senare visualiseras i text eller med bilder.

Nu behöver vi en spelplansklass, Board, som innehåller information om vilken typ av kvadrat som för tillfället finns på varje position på spelplanen.

Ett Board t.ex. innehålla en tvådimensionell array av lämplig storlek, där varje element är en SquareType. Att arrayer har ett fixerat antal element fungerar utmärkt i Tetris, eftersom spelplanens storlek inte ändras under spelets gång.

Board behöver också ha en konstruktor som tar en bredd och höjd på spelplanen som argument och skapar en lämplig tvådimensionell array. Detta verkar vara det enda vi behöver just nu, men fler fält och metoder kommer säkert att tillkomma när vi kommer längre med spelet.

Längre fram kommer vi att låta tetrominos flytta runt på spelplanen. Då kommer vi att behöva hantera kollisioner med existerande tetrominos på planen, så att vi inte flyttar något genom något annat.

Vi kommer också att behöva kolla om användaren försöker flytta en tetromino utanför spelplanens gränser (vänster/höger/botten). Hur gör vi detta? Ett sätt är att använda olikheter som räknar med tetrominons storlek och brädets storlek. Då måste vi även tänka på exakt hur tetrominon är roterad just nu, vilket komplicerar saken. Ett annat sätt är att utnyttja kollisionskoden, som ju ändå måste finnas. För att göra detta skapar vi ett speciellt enum-värde OUTSIDE som vi sedan lägger som en "ram" runt spelplanen. Ett försök att flytta en tetromino utanför planen blir då helt enkelt en "krock".

Vy-klassen som ska skapas behöver kunna få reda på hur stort ett Board är och vilken typ av kvadrat (om någon) som finns på en viss position. Detta ska den så klart inte få reda på genom att själv titta på fälten i Board (de ska ju vara privata). Istället krävs nya metoder i Board. De metoderna ska bland annat returnera information om en specifik position – returnerar du hela arrayen kan den ju ändras utifrån, och du låser också fast dig för hårt vid arrayrepresentationen.

Javas strängar är oföränderliga: Man kan inte ändra på dem när de väl har skapats. För att inkrementellt bygga upp en lång sträng använder man lämpligen klassen StringBuilder och dess append()-metoder. För att lägga till en radbrytning efter varje rad används "\n" (backslash n). När strängen är klar tas den fram som String-objekt med toString(). Här är ett exempel:

   // Create new StringBuilder.
   StringBuilder builder = new StringBuilder();
   
   // Loop and append values.
   for (int i = 0; i < 5; i++) {
       builder.append("abc ");
   }
   // Convert to string.
   String result = builder.toString();
   
   // Print result.
   System.out.println(result);

Givet en SquareType behöver vi veta vilken symbol den ska illustreras med. Man kunde tänka sig att detta skulle läggas in direkt i själva SquareType-objektet men då har vi blandat ihop modellen (SquareType) med ett specifikt sätt att visa modellen på (text). Istället får vi låta vyn känna till vilka SquareTypes som finns och ha en hjälpmetod som returnerar symbolen motsvarande en viss SquareType.

För vår testning vill vi också ha ett sätt att slumpa fram en spelplan. Detta kan ligga i en separat hjälpklass eller läggas in i klassen Board.

Efter spelplanen kommer själva Tetrisblocken. Det finns totalt 7 varianter i grundspelet, och vi kan tänkas vilja utöka detta på olika sätt i framtiden – genom nya former (utökning till pentominoes med fem kvadrater per block, penta=5) eller andra varianter (block som exploderar). Frågan är då hur man ska implementera block på bästa sätt för att tillåta sådana utökningar.

• En generell abstrakt klass + en konkret subklass per blocktyp (L, T, ...)? Det är så klart en möjlighet, men om vi tänker lite närmare på spelet inser vi att blocken egentligen inte beter sig olika. Därför skulle vi egentligen inte ha så mycket nytta av de olika subklasserna – vi skulle till exempel inte behöva "overrida" metoder från den generella klassen för att utnyttja subtypspolymorfism, och alla klasser skulle behöva samma fält för att lagra information. Det enda som skulle skilja sig mellan klasserna är formen på varje block, och detta är data, inte beteende.

  Viktig regel: Skapa bara nya klasser om de verkligen har olika beteende som ger större skillnad i koden. Skapa inte nya klasser när det räcker med att några värden skiljer sig.

• En enda klass? Det verkar vara ett bättre val. Och om vi sedan vill implementera exploderande block kan vi göra det med en enda ny subklass, snarare än sju olika subklasser ("exploderande L", "exploderande O", osv).

Vi skapar därför en enda blockklass, som vi kan kalla Poly (kort för Polyomino).

Vi behöver ett sätt för varje Poly-objekt att tala om hur det ser ut. Detta har inte att göra med visualisering (pixlar på skärmen) utan är en del av den fundamentala modellen för ett block (till exempel avgör det hur långt ett block kan falla). Därför ska det definitivt finnas med i Poly-klassen. Eftersom vi ska placera ut Poly-objekt på vårt Board kan vi med fördel representera denna på samma sätt. Vi väljer därför en tvådimensionell array för vår Poly.

Tanken är att klassen Poly ska kunna användas för vilken typ av block som helst, inklusive t.ex. block med 3 eller 5 kvadrater. Därför vill vi inte direkt i Poly hårdkoda kunskapen om exakt vilka blocktyper som finns. I stället låter vi konstruktorn ta in en tvådimensionell array av kvadrater som parameter. Den exakta storleken på arrayen bestäms då av den som anropar konstruktorn.

Vi behöver något sätt att skapa de sju sorternas Poly.

För att uppnå detta kan vi skapa en separat klass, TetrominoMaker. Klassen kan t.ex. ha dessa metoder:

    public int getNumberOfTypes() { ... }
    public Poly getPoly(int n) { ... }

En anropare kan då skapa en TetrominoMaker och anropa getNumberOfTypes() för att fråga om hur många blocktyper som den kan ge oss (just nu 7).

Anroparen kan sedan slumpa fram ett tal mellan 0 och getNumberOfTypes()-1 och anropa objektets getPoly() med detta som argument. Metoden getPoly() returnerar då ett nytt Poly-objekt av den givna typen.

getPoly() gör detta genom att skapa en 2D-array av lämplig storlek, fylla den med kvadrater motsvarande det begärda blocket, skapa en ny Poly för denna array, och returnera det nya objektet.

Vilken storlek ska då arrayen ha? För att underlätta för senare rotation av blocken är det en fördel att använda en storlek på 2x2, 3x3 eller 4x4, beroende på vilken tetromino som den innehåller. Arrayerna kan då skapas enligt vänstra kolumnen i följande bild (där de övriga kolumnerna visar hur blocken ser ut när de roteras, vilket vi kommer till senare). Blocket O ("kvadraten") ser ut att ligga i en array med storlek 4x3, men för att förenkla det för oss själva kan vi helt enkelt lägga det i storleken 2x2 istället.

Bilden kommer från en beskrivning av det standardiserade rotationssystemet.

Vår spelplan kan representera de block som redan har fallit ner. Detta representeras som en array av SquareTypes, vilket ger oss all information vi behöver för att rita upp det som är kvar av de block som fallit ner. Nu behöver den också kunna representera ett block som är på väg att falla ner, så att all information om spelets nuvarande tillstånd sparas på ett och samma ställe. Hur åstadkommer vi det?

Alternativ 1 är att de fyra kvadraterna (SquareType) från det fallande blocket läggs in i samma tvådimensionella array som används för att lagra de block som redan har fallit ner. Det har en fördel: Eftersom allt som ska ritas ut ligger lagrat på samma sätt som förut, behöver vi inte behöver ändra uppritningsfunktionen (BoardToTextConverter). Å andra sidan har vi en stor nackdel: När det fallande blocket flyttar sig ett steg (eller roteras) måste vi komma ihåg var vi hade lagt in det, ta bort dess SquareTypes från dessa positioner i arrayen och lägga till dem igen på nya positioner. Detta kan bli lite omständigt.

Alternativ 2 är att den tvådimensionella arrayen i Board bara lagrar de block som redan har fallit färdigt. Det block som fortfarande faller får Board hålla reda på genom att ha ett fält som pekar på en fallande Poly (eller null om inget block faller just nu) och två fält som anger dess x- och y-koordinater. Då blir det lätt att flytta det fallande blocket genom att helt enkelt ändra dess koordinater, utan att överhuvudtaget peta i Board:s tvådimensionella array. Det underlättar också framtida utökningar där ett block inte nödvändigtvis faller och roterar med ett "hopp" från ett läge till ett annat utan animeras jämnt och mjukt. Å andra sidan behöver vi ändra uppritningsfunktionen så den tar hänsyn till både de block som fallit färdigt och det fallande blocket.

I den här labben ska det andra alternativet användas. Det kräver nya fält och metoder i Board samt utökningar i BoardToTextConverter.

Just nu (utan mjuka animeringar) gäller alltså för varje position (x,y) som ska ritas ut (läggas till i textsträngen): (1) Om positionen täcks av en kvadrat i ett fallande block gäller denna SquareType. (2) Annars gäller den SquareType som anges av Board.

Det är nu dags att gå över från rent textformat till ett grafiskt gränssnitt.

Om du inte är van vid GUI-programmering med Swing i Java: Vänta till du har varit på GUI-föreläsningen.

För att förenkla steget in till ett GUI-program kommer du att börja med att skriva ett grafiskt gränssnitt som använder en grafisk textkomponent, en JTextArea, för att visa den gamla textrepresentationen av en "spelplan". Det verkar kanske som ett lite underligt sätt, men det gör dels att du kan börja med GUIt redan innan du lär dig hur man skapar egna komponenter, dels att du får ett enklare "mellansteg" så att du inte behöver göra om hela användargränssnittet på en gång. Det gör det också möjligt att göra en väldigt enkel animering av t.ex. nedfallande block genom att du i JTextArea byter ut texten i varje steg, istället för att som med System.out.println() skriva ut varje ny spelplan under den förra.

Så småningom behöver vi ha något sätt att driva spelet framåt, att få block att falla ner i lagom takt och så vidare.

Ett inte alltför ovanligt misstag är att man lägger in en loop som "stegar fram" ett steg, gör en paus av konstant längd, "stegar fram" nästa steg, och så vidare. Problemet är att när pausen är av konstant längd kommer tiden från starten av ett steg till starten av nästa att variera, beroende på hur lång tid själva steget tar, vilket är olika beroende på dator och CPU-belastning på datorn. Vi får göra på något annat sätt.

Som tur är finns en klass som heter javax.swing.Timer som vi kan använda för att få ett "steg" i spelet att köras regelbundet. Blanda inte ihop den med andra klasser som heter Timer, t.ex. java.util.Timer! Här ser vi en anledning till att man lägger klasser i olika paket.

I den här uppgiften ska vi bara göra en enkel utforskning av Timer. Senare, när vi har gått vidare till en fullständig grafisk komponent, kommer vi att titta närmare på lämplig modellering av spelet som helhet och var spelloopen egentligen ska placeras.

Det vi behöver veta kan vi då lära oss av följande exempel och beskrivningen under.

    final Action doOneStep = new AbstractAction() {
        public void actionPerformed(ActionEvent e) {
            // Gå ett steg i spelet!
        }
    };
    
    final Timer clockTimer = new Timer(500, doOneStep);
    clockTimer.setCoalesce(true);
    clockTimer.start();
    ...
    clockTimer.stop();

En Timer ser alltså till att Swings egna händelsehanteringstråd anropar en viss handling ("action") med jämna mellanrum. I detta fall är det 500 millisekunder mellan anropen, och det som anropas är den handling som vi kallade doOneStep. Genom att anropa setCoalesce(true) ser vi till att anropen inte "köas upp" om ett visst anrop till doOneStep() skulle ta för lång tid. Vi kan starta timern när spelet börjar och stoppa den när spelet är över.

I övrigt kan även clockTimer.setLogTimers() vara intressant för felsökning. Se även Javadoc-dokumentationen som vi länkar till ovan!

Det är viktigt att man granskar sin egen kod då och då, för att eventuella problem inte ska bli för långlivade. Ju tidigare man kan förbättra koden, desto längre tid har man att utnyttja de förbättringarna. Det gäller ännu mer i den här kursen, när ni själva håller på att lära er objektorientering och Java.

Innan vi går vidare med själva spelmekaniken är det dags att vidareutveckla resten av det grafiska gränssnittet för spelet en liten aning.

Det är nu dags att gå över från en textbaserad visning till en helt grafisk.

Om du inte är van vid grafikprogrammering med Graphics2D i Java: Vänta till du har varit på grafik-föreläsningen.

En JComponent behöver kunna rita upp sig själv när som helst, när Swings bakgrundstråd anropar den. Vi skall därför implementera metoden paintComponent() så att den ritar upp spelplanen som det ser ut just nu. Om metoden blir stor kanske den behöver delas upp i delmetoder / hjälpmetoder för att förbättra läsbarheten.

Tänk på att paintComponent() behöver rita upp både bakgrunden, de kvadrater som har ramlat ner på spelplanen, och det block (om något) som håller på att ramla ner.

Fundera på hur paintComponent() ska veta vilken färg (java.awt.Color) den ska använda för varje SquareType.

• Ett sätt är att använda en switch-sats med en gren för varje SquareType.

• Ett annat sätt är att den har en EnumMap<SquareType,java.awt.Color> som lagrar mappningen. En EnumMap är en mappning, en uppslagningstabell liknande det som kallas dictionaries i Python – i detta fall med en SquareType som nyckel och en Color som värde. I Java finns dock ingen specialsyntax för mappningar, utan det är en klass som alla andra, och objekten manipuleras med metoder som put() och get().

  Med denna lösning kan din komponent till och med ta in en EnumMap som konstruktorparameter, så kan den som skapar komponenten lätt konfigurera uppslagstabellen uppslagningstabellen (och därmed färgerna) utifrån – betydligt mer flexibelt än att hårdkoda en switchsats i paintComponent().

I det program du nu har skrivit har du själva fått hitta på ett sätt att få spelplanen att ritas om när något ändras. Det föreslagna sättet har varit att en timerhandling som utförs med regelbundna mellanrum både ser till att spelmodellen uppdateras (ett block faller nedåt) och att TetrisComponent därefter ritar om sig. Problemet med den lösningen är att timerhandlingen måste känna till precis vilka som vill veta när spelplanen ändrar sig. Vi får därmed en alldeles för stark koppling mellan två klasser (timerhandling och TetrisComponent) som egentligen inte alls borde behöva känna till varandra.

Ett annat sätt är att använda designmönstret Observer. I korthet innebär detta att vi ser spelplanen som något "observerbart" (Observable). Varje gång planen förändras på något sätt (t.ex. genom att ett block faller ner ett steg) kan den själv informera en eller flera "observatörer" (Observer). Varje observatör kan då själv registrera sig som intresserad av vad som händer med ett visst Board.

Fördelen med detta tankesätt är bland annat att timerhandlingen kan fokusera helt på att driva spelet framåt ett steg. När spelet drivs framåt ett steg är det sedan spelplanen som talar om för alla intresserade att något har hänt. En av dessa intresserade råkar vara TetrisComponent, som tidigare har registrerat sitt intresse.

Vi har faktiskt redan sett en användning av detta mönster i Javas GUI-bibliotek. Alla komponenter är observerbara, och alla lyssnare är observatörer. Metoder som addActionListener() lägger till en lyssnare, en observatör, som är intresserad av en specifik typ av handling. Klasser som JButton känner inte till era specifika lyssnare i förväg, men de har ett sätt för lyssnarna att registrera sitt intresse.

Nu är det dags att börja implementera den riktiga spelmekaniken i Tetris. Vi gör detta i flera steg. I stället för att som tidigare att utnyttja timerhandlingen till att slumpa fram en helt ny spelplan full av kvadrater ska den nu driva spelet ett steg framåt. Det är dock en dålig idé att lägga spelmekanik och spelregler i själva timerhandlingen – då skulle vi återigen blanda ihop två helt olika typer av funktionalitet.

En bättre variant är att du skapar en tick()-metod i Board och anropar den metoden från timerhandlingen. Metoden tick() kan sedan veta hur spelet drivs fram ett steg. Då hamnar kunskapen om spelets regler i Board, medan timerhandlingen används uteslutande för att driva spelet framåt i rätt fart. (Ett alternativ kan vara att separera spelmekaniken ytterligare och placera den i en TetrisGame-klass.)

Metoden tick() behöver titta om spelplanen just nu innehåller ett block (Poly) som håller på att ramla ner. I så fall flyttar den det blocket ett steg nedåt. Annars slumpar den fram en blocktyp (T, L, ...) och placerar ett nytt block av den typen överst på spelplanen, centrerat. Mer spelmekanik tillkommer senare.

Eftersom du nu har programmerat en del i Java börjar vi också gradvis beskriva uppgifterna lite mindre detaljerat. Fråga gärna assistenten om du vill ha hjälp!

Nu är det dags att få blocken att stanna när det nått botten av skärmen / spelplanen. Detta kräver så klart att du tittar på det fallande blockets form och beräknar när den nedersta kvadraten i blocket når botten.

Om ett block (Poly) redan har fallit ner till botten av skärmen och försöker falla ett steg till – vilket inte går – ska dess kvadrater överföras till själva spelplanen i blockets slutliga läge ("läggas in i den tvådimensionella arrayen"). Spelplanen ska sedan övergå i ett läge där det inte har något fallande block (t.ex. genom att pekaren till det fallande blocket återigen blir null), så att nästa tick() kan se att det är dags att slumpa fram ett nytt fallande block. Vi har alltså:

• tick(). Ett antal gånger: Vi beräknar om det skulle gå att flytta blocket ett steg längre ner utan att någon av dess kvadrater hamnar under nedersta kanten på skärmen. Det går, så blocket flyttas till nästa position.

• tick(). Ett antal gånger: Vi beräknar om det skulle gå att flytta blocket ett steg längre ner utan att någon av dess kvadrater hamnar under nedersta kanten på skärmen. Det går inte, så blocket är redan på positionen längst ner. Dess kvadrater kopieras in till rätt koordinater på spelplanen och själva blocket (Poly) "tas bort". Nu finns alltså inget fallande flyttbart block, men motsvarande kvadrater finns inlagda "permanent" i spelplanen. Utåt ser det ut som att spelet står still i ett tick – ingen skillnad syns.

• tick(). Metoden ser att det inte finns något block som håller på att ramla ner, så ett nytt slumpas fram på översta positionen.

• tick(). Som i första punkten...

Nu lägger vi till kollisionshantering mellan block. Med detta menas att ett block inte ska kunna "ramla förbi" ett annat utan att block ska staplas ovanpå varandra. Spelets beteende kan t.ex. vara så här:

• tick(). Blocket flyttas ned ett steg och har nu kvadrater omedelbart under sig.

• tick(). Blocket kan inte flyttas ett steg ned. Hanteras som tidigare genom att lägga in kvadrater i arrayen.

• tick(). Det finns inget block som håller på att ramla ner, så ett nytt slumpas fram. Kollisionshantering upptäcker att detta block inte ens kan placeras på översta positionen, så blocket placeras inte ut och gameOver-flaggan sätts.

• tick(). Eftersom gameOver-flaggan är satt gör vi inget.

Dags att lägga till tangentbordsstyrning av block så att de kan flyttas åt höger och vänster. Tangentbordsstyrning kan göras med hjälp av key bindings kopplade till din TetrisComponent. Här får du också en övning i att läsa ut information ur Java Tutorial!

Tänk på att man normalt kan flytta ett block flera steg åt sidan under samma tick. Eftersom key bindings hanteras asynkront ska detta fungera automatiskt.

Om man ska ha en chans att fylla rader så de försvinner behöver man också kunna rotera blocken. Detta kan kännas knepigt, men är viktigt av två anledningar:

• Det gör att spelet verkligen blir spelbart...

• Det är ett bra test av koden vi har skrivit tidigare: Är den korrekt, eller beror den på underförstådda antaganden som egentligen inte är sanna?

Så hur roterar man ett block? Det enklaste sättet att rotera vår tetromino åt höger är genom att flytta alla våra SquareType enligt följande bild:

Vi gör då en funktion rotate() i Poly som tar en boolean som inparameter. Här används inparametern för att bestämma om vi roterar åt vänster eller höger. Rent praktiskt behöver vi en ny tom array eller en ny Poly som vi efter hand kan stoppa in de olika rutornas innehåll i. När vi är klara byter vi till den nya arrayen/polyn.

För ytterligare ledning kan du se följande metod. Den skapar först en ny Poly med samma bredd som den nuvarande Polyns höjd och tvärtom. Därefter kopierar den SquareTypes till den nya Polyn enligt ovanstående mönster.

Metoden roterar enbart åt höger. Tänk på att two wrongs don't make a right – but three lefts do, och tvärtom. Med andra ord, man kan rotera åt vänster genom att rotera åt höger tre gånger. Alternativt kan man så klart skapa en motsvarande rotateLeft() som roterar åt vänster i ett enda steg.

public Poly rotateRight(){

    Poly newPoly = new Poly(height, width);

    for (int r = 0; r < height; r++) {
        for (int c = 0; c < width; c++){
            newPoly.squares[c][height-1-r] = this.squares[r][c];
        }
    }

    return newPoly;
}

Notera: Om ni bara har använt precis så många rutor som behövs för att en Poly ska få plats, kan ni få oväntade resultat. Nedan skulle t.ex. "balken" inte rotera runt sin mittpunkt utan runt sin övre vänstra kvadrat:

Om man istället låter "balken" vara i en array av storlek 4x4, som i rotationsstandarden som presenterades tidigare, roterar allt runt den arrayens centrumpunkt:

Nu är det dags att lägga till poänghantering i spelet. Vi kan använda en enkel poängsättning där man får:

• 100 poäng om 1 rad försvinner
• 300 poäng om 2 rader försvinner på samma gång
• 500 poäng om 3 rader försvinner på samma gång
• 800 poäng om 4 rader försvinner på samma gång

Detta är en förenkling av ett vanligt poängsystem som även tar hänsyn till olika spelnivåer (hastigheter) och vissa finesser som vi inte har implementerat i den här enkla Tetris-varianten.

Nu fungerar poängen, men man kan bara se dem medan man spelar. Det vore bra om man kunde lagra poängen så att man efter varje spel kan se en highscorelista.

Vi tänker oss nu att man vill kunna spela många parallella spel, och att man i alla de spelen vill kunna använda sig av samma gemensamma highscorelista. Då är frågan hur samtliga spel ska kunna komma åt denna enda lista. En möjlighet är att det finns en central plats där alla spel "skapas", och att denna alltid skickar med highscorelistan till spelen. Det skulle säkert fungera i det här fallet. En annan möjlighet är att vi använder oss av ett designmönster som heter Singleton. Där ser man till att det enbart kan skapas ett enda objekt av en viss klass, och att detta objekt blir tillgängligt på ett enkelt sätt för de som behöver det.

En Singleton med "ivrig initialisering" (skapa objektet direkt, inte vid första anropet) kan i Java implementeras på det här sättet:

public class HighscoreList {
    // Skapa bara objekt av denna typ EN gång, när klassen laddas.
    private static final HighscoreList INSTANCE = new HighscoreList();

    // Privat konstruktor, så ingen annan kan skapa fler objekt.
    private HighscoreList() {
        ...
    }
 
    // Låt andra komma åt det unika objektet
    public static HighscoreList getInstance() {
        return INSTANCE;
    }

    // Flera fält och metoder, precis som i vilken klass som helst
    private ...
    public ... 
}

För att komma åt det unika HighscoreList-objektet kan man nu helt enkelt anropa HighscoreList.getInstance(). Därefter kan man använda detta objekt som vanligt, men man vet att alla andra som anropade HighscoreList.getInstance() också har exakt samma objekt.

Det finns även flera andra sätt att implementera Singletons i Java. Viktigt är att det finns flera sätt som verkar rimliga på ytan, men som inte alls fungerar. Slå alltid upp korrekt sätt så du är säker att det fungerar! Överkurs: Vissa sätt att implementera double-checked locking fungerar inte i multitrådade program.

Nu kan vi se highscorelistor, men de hamnar i godtycklig ordning. Vi vill se den högsta poängen först!

För att åstadkomma detta behöver vi kunna sortera listorna. Den större delen av en sorteringsalgoritm brukar vara generell och fungera för godtyckliga sorters element, och den delen finns så klart "inbyggd" i Java. Men sortering bygger oftast på att man kan jämföra två godtyckliga element i en lista och tala om vilket av dem som borde vara först, och just denna del är helt och hållet specifik för varje elementtyp. I vårt fall handlar det alltså om att tala om för sorteringsalgoritmen hur man tar reda på vilket av två Highscore-objekt som ska vara först i den sorterade listan.

Det finns flera olika sätt att göra detta på. Ett sätt är genom designmönstret Strategy. Detta låter oss "plugga in" jämförelser genom att först skapa en jämförare, ett objekt som vet hur man jämför Highscore-objekt, och därefter skicka med denna jämförare som parameter till sorteringsmetoden. Jämförarobjektet är alltså ett sätt att implementera en sorteringsstrategi som sorteraren kan använda sig av.

Vilken typ ska "jämförar-parametern" till sorteringsmetoden ha? I Javas standardsortering används gränssnittet Comparator. Detta är ett "generiskt" gränssnitt, som också talar om vilken typ <T> man kan jämföra ett objekt med. Vi diskuterar detta i detalj under föreläsningen om datatyper. Har du inte läst om detta än kan du ändå följa med i instruktionerna.

public interface Comparator<T> {

    /** Compares its two arguments for order. 
    Returns a negative integer, zero, or a positive integer 
    as the first argument is less than, equal to, or greater than
    the second.  */
    public int compareTo(T o1, T o2);
}

Detta gränssnitt finns redan i Java. Vi behöver nu implementera det i en poängjämförare. Vad vi jämför (typen T) är alltså Highscore:

public class ScoreComparator implements Comparator<Highscore> {

    public int compare(Highscore o1, Highscore o2) {
        ...
    }
}

Vi kan sedan använda den statiska sorteringsmetoden i Collections-klassen:

List<Highscore> scores = ...;
...

Collections.sort(scores, new ScoreComparator());

Du har nu implementerat ett spel, läst om varför vi implementerar på ett visst sätt, och på det sättet lärt dig mer om objektorienterad modellering och programmering. Du har också fått en praktisk användning av flera designmönster: Model-View-Controller, Observer, Singleton, och Strategy.

Som synes resulterar den här labben inte nödvändigtvis i ett 100% fullständigt spel. Poängen sparas inte i en fil, blocken faller inte snabbare när tiden går så att spelet blir svårare, och så vidare. Det finns två anledningar till det: Dels skulle det mest kräva mer av samma typ av programmering som du redan har provat på, dels måste du ha gott om tid över till projektet.