Bookmark and Share

Svårighetsgrad
Svårighetsgrad
Betyg (1 röster)
BetygBetygBetygBetygBetyg
 

MonoAsteroids - Del 4

Inledning

Denna artikel är en direkt fortsättning på artikeln MonoAsteroids - Del 3. Det är nu dags för en storstädning samt att lägga till meddelandehantering och Game States. Vi tittar även lite närmare på Mediator designmönstret.

Artikeln är mer ett stöd till den videogenomgång som mer steg för steg går igenom alla moment. Videogenomgången hittar du i slutet av artikeln.

Mediator

Ett designmässigt problem uppstår om Player ska bestämma när nya skott ska produceras. Plötsligt måste Player känna till eller på något vis signalera spelet att sett skott ska läggas till.

Inom programmering finns en term som heter design patterns. Det är mönster som återkommer inom programmering som löser ett vanligt förekommande problem. Det problem vi har kan lösas med ett design pattern som heter Mediator.

Tanken med Mediator är att två objekt kan kommunicera med varanda utan att varken känna till eller vara beroende av varandra. Systemet fungerar som ett meddelandesystem där men prenumererar på meddelanden av en viss sort och sedan, vid behov, kan skicka meddelanden.

I vår omplementation så har vi valt att använda ett enklare designmönster som heter Singleton. Med singleton så såkerställer vi att det bara finns en instans av klassen som vi når via den statiska klassmedlemmen Instance. Vi implementerar Mediator i en klass vi kallar Messenger som främst erbjuder metoderna Send och Register.

Mer info om Mediator kommer i en separat artikel. Vi vill samtidigt varna för att vår implementation är rätt enkel och är varken trådsäker eller speciellt resurssäker.

Meddelanden

Vi skapar också klasser som beskriver olika sorters meddelanden och som innehåller den data som är viktig för respektive meddelande.

Vi behöver ett meddelande för att signalera nya skott som vi skapar med klassen AddShotMessage. Sen behöver vi ett meddelande för att signalera ändring på spelets tillstånd via klassen GameStateChangedMessage.

Game States

Innan vi har ett komplett spel så måste vi kunna tillåta att spelet befinner sig i olika tillstånd, sk. states. Först ser vi till att skapa en enum som beskriver i vilka olika tillstånd spelet kan befinna sig i.

Sedan ser vi till att använda oss av vårt meddelandesystem för att skicka uppdateringar/förfrågningar om att skifta tillstånd. Det är upp till spelet att prenumerera på dessa meddelanden och på så vis centralt på ett enda ställe hantera alla övergångar mellan olika tillstånd.

GameObjectManager

En stor del i själva städningen är att införa klassen GameObjectManager som kommer att ha hand om alla GameObject objekt (förutom Player). Denna klass är bara förflyttning av gammal kod. Här dyker också första exemplet på användandet av meddelandesystemet upp.

Videogenomgång

Ytterligare ändringar i kod

Som tidigare nämnts så är texten i artikeln här mest ett stöd för videogenomgången. Följ först videogenomgången sedan kan du jämföra din kod med den färdiga som listas under detta avsnitt.

Undvik klipp och klistra! Du lär dig mer av att skriva koden steg för steg när du följer videogenomgången.

Viktiga begrepp

  • design patterns
  • Mediator

Kommentarer

1 inlägg