Atoms

Denna artikel kommer inte att ha något färdigt projekt att ladda hem i slutet. Tanken är att du som läsare ska kunna följa artikeln och skapa det som i slutändan kommer att bli en spelidé som vi kallar ”atoms”. Spelidén är inte färdig men innehåller ett moment av ASMR-ljud. Ungefär som när du inte kan sluta ”ploppa” plastbubblor. Låter det lite knasigt? Kolla videon nedan så förstår du nog vad vi menar.

Denna artikel passar dig som redan har gjort några enkla MonoGame projekt och vill testa något som innehåller lite klasser och fysik.

Design

Som videon ovan visar så ska vi leka lite med enkel fysik och grafik och skapa ”atomer”. Det finns 4 olika tillstånd för våra atomer; trippel blå, trippel röd, röd och död. Trippel röd är den atom vi styr med musen innan den delas till 3 röda delar. De röda delarna kan i sin tur dela trippel blå till nya röda. De röda delarna lever en kort stund innan de sönderfaller och dör.

Vi kommer att behöva några olika klasser.

  • Atom – en beskrivning av en atom oavsett vilket tillstånd den befinner sig i.
  • AtomComparer – en hjälpklass för att sortera atomer. Denna klass kommer först att användas i slutskedet av projektet.
  • AtomManager – en hanterare för alla atomer som sköter kollisionshantering och uppritning.
  • AtomState – en enum för att beskriva de tillstånd atomerna kan befinna sig i.
  • AtomGame – en standard MonoGame Game-klass som vi bara bytt namn på.

Ett nytt projekt & några klasser

  • Skapa ett nytt MonoGame projekt, t.ex. ”MonoGame Windows Projekt”.
  • Byt namn på Game1.cs till AtomGame.cs
  • Lägg till nya tomma klasser; AtomComparer.cs, Atom.cs, AtomManager.cs, AtomState.cs

Du bör nu ha en Solution Explorer som liknar bilden. Vi har inte lagt till en enda rad kod än, vi har bara förberett strukturen på projektet så det blir lättare att följa guiden.

Content (grafik, ljud, fonter)

Nästa steg är att lägga till all grafik och ljud som vi kommer att använda. Det är bara 4 filer; ball.bmp, redball.bmp, gameFont.spritefont och bloop.wav.

1. Ladda hem filen atoms_content.zip vi länken ovan.

2. Extrahera (packa upp) filerna, t.ex. på ditt Skrivbord. De kan inte ligga kvar i zip-filen om du ska använda dem.

3. Starta MonoGame Pipeline Tool via Visual Studio (dubbelklicka på Content.mgcb). Högerklicka och lägg till alla filer med ”Add”->”Existing Item..”.

Om alla filer är inlagda ska du kunna bygga din Content antingen via menyn ”Build” eller snabbtangent F6. Resultatet borde bli grönt och se ut som:

Atomernas tillstånd

Den första kodfil vi ska bearbeta är AtomState.cs. Vi behöver kunna skilja på de olika tillstånd som atomerna kommer att befinna sig i. Vi har redan nämnt dem en gång. En smidig variant är att använda enum för sådana fasta vädren. Filen blir ganska kort:

Atomen

Vi behöver sedan lägga in kod som beskriver hur en atom (oavsett tillstånd) ska fungera i filen Atom.cs.

Atomen behöver givetvis data om vilken position den har (Position), hastighet (_speed), rotation (Angle), vilket tillstånd den befinner sig i (Type), etc. Beroende på tillstånd så kommer atomen ha en olika stor radie (Radius). Atomen kommer också att rotera med en hastighet (_angle_speed) antingen mot- eller medsols. När uppritningen sedan ska ske så måste vi veta i vilken ordning atomerna ska ritas, därför har varje atom en Zorder. Om du tänker dig ett koordinatsystem med X- och Y-axel så för vi in en tänkt tredje Z-axel. I detta fall är det bara en tankemodell där vi ger varje atom ett Z-värde för sortering när den sen ska ritas ut.

Vi kikar på den färdiga klassen och tittar sen på fler detaljer.

Konstruktorer

Efter våra data-attribut i klassen så kommer 3 olika konstruktorer. Varför 3 olika kan man undra? Jo ibland underlättar det att kunna skapa objekten på olika sätt. Vi har först den så kallade ”baskonstruktorn” (default constructor) Atom() som inte har några inparametrar. Denna konstruktor gör inställningar som gäller alla sorter atomer. I konstruktorn sätter vi radien till 10, tillståndet till TRIPPLE_BLUE, slumpar en rotationsriktning (rad 22-25), slumpar en startposition (rad 27), slumpar en riktning (rad 29) och sätter en hastighet baserad  på riktningen (rad 30).

Riktningen är lite speciell då värdet kommer att variera mellan 0 och 2π. Detta då datorer (och vetenskap generellt) räknar med radianer istället för grader (0-360°). Men det visste du säkert redan.

Svaret på varför vi vill ha 3 olika konstruktioner är just att vi kan göra fler sätt som kanske gör lite speciella inställningar. Ibland vill vi skapa en annan typ än TRIPPLE_BLUE. Vi har därför Atom(AtomState type) som variant där vi kan skicka in vilken typ vi vill skapa. Det som är praktiskt med vår design är att vi återanvänder Atom()-konstruktorn genom att på rad 35 ange : this(). På så viss kommer Atom()-konstruktorn köras innan Atom(AtomState type)-konstruktorn körs.

Sista varianten är Atom(Vector2 position, Vector2 speed, AtomState type) som också anger position och hastighet. Märk väl att denna i sin tur använder Atom(AtomState type) via rad 47 : this(type) som i sin tur använder Atom().

Update

Kvar har vi Update-metoden. Här sker själva förflyttningen av atomen (rad 55). Om typen är RED så sjunker hastigheten varje frame med 2%. Om sedan hastigheten blir för låg så sönderfaller atomen helt och försvinner, vi sätter då tillståndet till DEAD. Rotationen uppdateras på rad 64.

Rad 66-85 genomför koll så att atomen inte åker utanför skärmen. Om man hamnar utanför i någon riktning så vänds respektive hastighet i X- eller Y-led.

Sortering av atomer

Vi kommer att behöva sortera våra atomer för att optimera kollisionsberäkningarna. Om vi inte sorterar dem så kommer vi att få problem! Vi kommer att ha två listor med atomer, de blåa atomerna och de röda atomerna. Vi ska nu försöka förklara själva problemet först.

Här har vi 180 atomer. När bilden tas finns det ca 120 blåa och ca 120 röda atomer. För att kontrollera kollision behöver varje blå atom kollas mot varje röd atom. Hur många kombinationer blir det?
Jo, det blir 120*120 = 14 400 kollar varje frame!

Här hade vi 1000 blåa atomer. Innan alla sprängdes så hade vi vid en tidpunkt 500 blåa och 1500 röda atomer. Antal kombinationer blir 500*1500 = 750 000 varje frame!

Problemet som beskrivs ovan är att antalet beräkningar växer kvadratiskt med antalet atomer. På dataspråk brukar man då tala om ett ”Ordo”, O(n2) problem. Resultatet blir att CPU’n blir överbelastad och hinner inte med, vilket i sin tur resulterar i ”frame drops”, alltså att uppritningen hackar.

I filen AtomComparer.cs skriver vi en klass som talar om hur vi kan sortera atomerna. Tanken är att vi sorterar dem efter vilket X-värde de har på skärmen. Det kommer att kunna ge oss två sorterade listor på blåa respektive röda atomer när vi sedan ska börja jämföra och se om de kolliderar. Kodfilen kommer att se ut såhär:

När vi sedan kollar kollision så går vi precis som tidigare igenom varje blå atom men istället för att kolla mot alla röda atomer så kan vi nu göra ett urval. Om vi håller reda på ett startIndex i den röda listan för vilka atomer som rent X-värdemässigt skulle kunna kollidera. Då kan vi utgå från startIndex och fortsätta ”framåt” i listan tills vi når X-värde som är större än den blå atomens X-värde + radie. Låter konstigt? Kolla bilden nedan.

Eftersom alla atomer är sorterade efter X-värde i våra listor så kommer vi aldrig att behöva kolla alla blåa atomer mot alla röda atomer längre. Vi kan nu kolla alla blåa atomer mot alla röda atomer som befinner sig inom samma gula ”remsa” som bilden ovan visar.

Antalet beräkningar i fallet med 1000 atomer blir nu annorlunda! Hur många röda atomer kan vi tänka oss i snitt per ”remsa”? Om det finns 1500 röda så kanske 20 ungefär. Totalt alltså 500*20 = 10 000 beräkningar. Inte illa! Även om vi  gissar fel och det är 40 per ”remsa” så blir det 500*40 = 20 000 vilket inte är mycket mer beräkningar än när vi hade 180 atomer utan optimering.

AtomManager

Vi är nu redo att diskutera hur en klass som håller reda på alla atomer skulle kunna se ut. Klassen ska ha ansvar för att uppdatera, rita ut, kolla kollision samt dela atomer. Resultatet är AtomManager.cs

För att klassen ska kunna sköta om alla atomer så har vi dem i listorna _blueAtmos och _redAtoms. Vi har en LoadContent() som ser till att ladda grafik och ljud som behövs (_soundFx, _textureRed, _textureBlue). Vi har en _startBall som är den trippel röda atomen som vi styr med muspekaren. Vi har en _ballCount för att beräkna Z-värde på atomerna samt en _soundDelay som förhindrar att vi spelar upp ljudet för ofta.

Vi har en Matrix _rot120Deg som är lite speciell. Det är en rotationsmatris som är fast inställd på att rotera vektorer 120°. Varför just 120°, jo när vi rutar upp trippel atomer så ritar vi tre små atomer fast med 120° mellan. När sedan atomerna ska delas så är det också användbart att kunna räkna ut och rotera så de får rätt hastighet.

Restart

Här nollställs allt. Det Skapas 180 atomer och ses till att vi har en _startBall.

Update

Här görs de typiska sakerna som förflyttning via varje atoms Update (rad 59). Tar bort döda atomer (rad 60).

Rad 62-88 sköte vår kollisionshantering. Denna är lite speciell då den bygger på diskussionen om att sortera atomerna efter X-värde som vi tidigare nämnt. Vi anropar här CheckCollision() vid behov mellan blåa atomer och röda atomer.

På rad 90 så kollas om vi har en _startBall, i så fall uppdateras den och ser till så att den följer muspekaren.

Rad 96-102 undersöker om vi ska spränga _startBall och påbörja kedjereaktionen.

Rad 104 och 105 ser till att våra listor på atomer hela tiden är sorterade efter X-värde med hjälp av AtomComparer.

Draw

Denna metod är kanske mins intressant. Här ritas alla blåa och röda atomer samt _startBall om vi har en sådan fortfarande.

CheckCollision

Denna hjälpmetod undersöker först så att vi verkligen jämför en blå med en röd atom (rad 125). Sedan sker en beräkning på cirklarnas avstånd med hjälp av atomernas position samt deras radier. Om avståndet mellan atomerna är mindre än deras sammanlagda radier så har vi en kollision (rad 130). Då sprängs båda atomerna (rad 132-133) samt sätter tillståndet DEAD om någon av atomerna var en röd ensam atom.

Explode

Detta är en hjälpmetod till CheckCollision. Det är endast trippel blåa atomer som kan sönderdelas (rad 144). Här spelas ljudeffekten max en gång per frame (rad 149), därav behovet av _soundDelay. Vi räknar ut de tre olika riktningarna som atomen delas upp i. Vi räknar ut en riktning med v1 (rad 156) sedan kan vi enkelt rotera denna riktning två gånger med _rot120Deg och matrisens magi så att vi får v2 och v3.

Sist så skapar vi tre nya röda små atomer och sätter deras hastighet baserat på v1-v3 (rad 161-163).

DrawAtom

Detta är en hjälpmetod till Draw(). Här räknar vi ut tre riktningar v1-v3 på samma vis som i Explode(). Vi använder sedan denna data om vi ska rita upp en trippel röd eller en trippel blå atom. Det sista alternativet är en ensam röd atom.

Allt sätts ihop

Du har redan skapat alla klasser som behövs nu. Det sista som återstår är att använda allt via AtomGame.cs. Tänk på att du ska ha döpt om Game1.cs till AtomGame.cs.

Vi gör egentligen inte mycket i själva spelklassen. Vi laddar en font som vi använder för att rita ut hur många atomer som finns kvar (rad 69). Vi skapar såklart en AtomManager, ser till att den får ladda sina prylar (rad 38), uppdaterar den (rad 58) samt ritar upp den (rad 68). Vi har också en koll på om vi trycker ned knappen ”R” (rad 55), i så fall startar vi om allt.

Du ska nu har ett körbart projekt. Kan du ”ploppa” alla atomer? Testa annars med att öka antalet på skärmen.

/Lycka till

Scroll to top