Share
Vi är nu halvvägs genom denna serie, och hittills har vi täckt mycket. I den tidigare handledningen lade vi till ett poängsystem till vårt spel, vi tilldelade slutligen "gravitation" till blocken, och vi förbättrade vårt matchande system. I denna handledning kommer vi att göra några små förbättringar i vårt bytessystem, lägg till de flytande punkterna som du kan se i den slutliga versionen av spelet och avsluta vårt matchande system en gång för alla.
Här är en demonstration av spelet vi arbetar mot genom hela serien:
Just nu har spelet genomfört en mycket enkel bytesmekaniker. Medan systemet vi använder för att utföra dessa swappar är mycket effektivt, finns det två problem som du kan stöta på medan du spelar, och båda måste fixas innan vi går längre.
Dessa problem beror på samma idé: att bytessystemet inte tar hänsyn till spelfältets gränser.
Vad betyder detta, exakt? Tja, först om du vill kan du flytta ett block utanför spelfältet åt vänster eller höger genom att göra en byte som den som illustreras nedan:
Om du går in i spelet och gör det här bytet ser du att spelet inte gör något för att stoppa dig och fungerar som om spelfältet fortsätter för alltid i en horisontell riktning. Anledningen till detta är att just nu spelfältet gör fortsätt alltid horisontellt.
Eftersom vi aldrig definierat var vänstra och högra gränserna för spelfältet, eller ens som spelfältet har lämnat och högra gränser, försöker aldrig spelet att stoppa spelaren från att flytta blocket längre fram till sidan. Detta problem kommer också upp när du byter ut den andra kanten av spelfältet också.
För att lösa detta problem lägger vi till några nya villkor för Blockera> På DragDrop-droppe Händelse. Gå till den här händelsen och lägg till det här villkoret till delhändelsen som kontrollerar för vänstra byte:
Skick: LeftBlock> Jämför X Jämförelse = Större eller lika X = SPAWNX
Lägg nu till detta villkor till delhändelsen som kontrollerar rätt swappar:
Skick: RightBlock> Jämför X Jämförelse = Mindre eller lika X = SPAWNX + Block.Width * 8
Dina vänster och höger byta händelser ska nu se ut så här:
Dessa nya villkor som vi lagt till används av bytesevenemang som en check för att säkerställa att bytet ligger inom spelfältets horisontella gränser. Den första säkerställer att den position som blocket skulle bytas till är inte längre till vänster än de vänstra blocken, och den andra säkerställer att positionen blocket byts till inte längre till höger än höger- de flesta block.
Med den andra användes en formel med Block.Width för att hitta var de högsta blocken är för att säkerställa att om storleken på blocken ändras kommer det inte att förhindra att detta tillstånd fungerar.
Om du kör spelet borde du inte längre kunna göra horisontella swappar som skulle placera block utanför spelområdet.
Det andra problemet vi har är att spelet inte hindrar dig från att byta ett block under spelfältet. Öppna spelet och försök att göra en byte som den jag har illustrerat i bilden:
Efter att ha gjort det här bytet bör du ha sett blocket i huvudsak bara försvinna bakom spelfältets nedre del och blocken som var ovanför det borde ha fallit för att fylla i det nu tomma utrymmet. Återigen är det här problemet för att vi aldrig definierat var fältets undersida är.
I den tidigare handledningen förklarade vi att blocken borde sluta falla efter att ha nått en viss höjd, men vi sa aldrig om det var okej att ett block skulle gå under den höjden när vi utförde ett byte.
Att fixa detta blir lika enkelt som de två tidigare frågorna. Gå till delhändelsen som kontrollerar nedåtgående swappar och lägg till detta villkor:
Skick: BottomBlock> Jämför Y Jämförelse = Mindre eller lika Y = SPAWNY
Din kod för det här avsnittet ska nu se ut så här:
Precis som i föregående skick garanterar detta att bytet inte skulle placera blocket i ett område utanför spelfältet. I det här fallet ser det på området under spelfältet.
Om du testar ditt spel på den här tiden borde du nu inte kunna göra swappar som lägger blocket under basen av spelfältet.
Vid denna tidpunkt har vi löst problem med bytesystemet och kan fortsätta att göra vårt poängsystem ännu bättre.
Just nu är vårt poängsystem ganska effektivt. Det fungerar som vi menade, och visar redan allt korrekt. Trots det, om du gav spelet till en spelare och satte dem ner med det, kanske de inte kan berätta exakt hur många poäng de fick från varje grupp de gjorde, eftersom spelet kan röra sig snabbt.
För att lösa problemet kommer vi att lägga till text popup-fönster som visar hur många poäng spelaren gör från alla grupper de bildar. Detta kommer att tillföra extra visuell känsla till spelet, och det kommer att göra det klart för spelaren hur värdefulla större grupper kan vara.
Innan vi kan börja lägga till funktionaliteten måste vi skapa ett nytt objekt som ska fungera som popup-text, så följ dessa steg.
Accentsconagua
FloatingPointsText Spelfält 616, 250 127, 43 0 Calibri, fet, 24 255, 255, 255 1,25.Det objekt vi just skapat kommer att användas för att skapa den flytande texten som talar om hur många poäng en given grupp ger dem. Nu när vi faktiskt har det här objektet måste vi implementera det så att när spelaren gör en match kommer den att kasta en ny instans av objektet och ändra texten för att visa rätt antal punkter.
För att gissa punkttexten lägger vi till två nya åtgärder till NumMatchesFound kontroller i FindMatches fungera.
Gå till FindMatches funktionen och lägg till dessa två åtgärder till slutet av varje NumMatchesFound> 3 kontrollera:
Åtgärd: System> Skapa objekt Objekt = FloatingPointsText Layer = 2 X = Block.X - Block.Width / 2 Y = Block.Y - Block.Width / 2 Action: FloatingPointsText> Ange texttext = NumMatchesFound * 10
Din FindMatches funktionen ska nu se ut så här:
Så vad gör dessa åtgärder? Den första åtgärden skapar FloatingPointsText objekt ovanpå det första blocket i gruppen och den andra multiplicerar antalet block i gruppen med 10, precis som vår poängformel gör, och ställer texten på det nya objektet till det numret.
Om du kör spelet vid denna tidpunkt bör du märka att texten inte rör sig alls. För att lösa detta problem ska vi lägga till en ny händelse i vårt spel.
Gå tillbaka till Event Sheet 1 och lägg till en ny händelse:
Skick: System> Varje Tick-åtgärd: FloatingPointsText> Flytta i vinkel Vinkel = -90 Avstånd = 0,25
Din nya händelse ska se ut så här:
Om du kör spelet nu ser du att texten flyttar.
Vid denna tidpunkt, vår FloatingPointsText fungerar som vi vill ha det, men du kanske har märkt en liten fråga nu när systemet är på plats. Frågan i sig härrör från det sätt som matchningssystemet fungerar, och nu när vi kan se att det fortfarande finns ett problem med matchning, kan vi bestämma oss för att fixa den här sista frågan och sätta vårt matchande system i sängen.
Om du inte vet vilken fråga jag pratar om, gå in i spelet och skapa en grupp som innehåller fyra kvarter. När din grupp är gjord bör du se något som liknar vad jag har i bilden nedan:
Som ni kan se har vi faktiskt två instanser av de flytande textobjekten. Om du gör en grupp med fem Blocks blir problemet ännu värre och du ser faktiskt tre exempel på punkttexten.
Orsaken till det här problemet är baserat på hur matchningar upptäcks. Just nu tittar vårt matchande system på varje block individuellt och ser i högerriktningen och nedåtriktningen för att hitta matchningar. På grund av detta är det matchande systemet faktiskt att hitta tre olika storlek grupper här, även om det faktiskt bara är en stor grupp.
Den första gruppen kommer att hittas när den börjar med Block A och innehåller fem block:
Den andra gruppen kommer att hittas när den börjar med Block B och innehåller fyra block:
Och den tredje gruppen kommer att hittas när den börjar med Block C, och kommer att innehålla tre kvarter:
Så, just nu är vårt matchande system mycket ineffektivt - och brutet - eftersom det kontrollerar samma block flera gånger och registrerar fler grupper än det faktiskt finns.
Att lösa problemet är faktiskt mycket enklare än det kan tyckas i början.
Frågan här beror främst på det faktum att det matchande systemet inte har någon väg att veta om blocket det börjar med är faktiskt början på gruppen. Om vi kunde garantera att vi bara tittat på block som var längst till höger eller högst upp inom de grupper de tillhörde, skulle det matchande systemet vara effektivt som-är.
Så allt vi behöver göra är att lägga till ett villkor eller händelse som säkerställer att det inte finns några matchande block ovanför eller till vänster om det block vi börjar med och att berätta funktionen när den har utfört denna kontroll så att den kan fortsätt normalt om blocket det tittar på är gruppens start.
Det första vi lägger till är en ny parameter för CheckMatches fungera. Denna parameter kommer att vara ett heltal och det kommer att vara antingen 1 eller 0.
Om parametern är 1, det kommer att indikera den funktion som den behöver för att utföra kontrollen för att säkerställa att den tittar på det inledande blocket i gruppen; om det är 0, det kommer att indikera den funktion som den har redan utförde denna kontroll och kan fortsätta normalt för att avgöra om gruppen består av tre eller flera block.
Så börja med att gå till FindMatches fungera. I den här funktionen ringer du CheckMatches dubbelt. Eftersom det här är första gången du ringer CheckMatches för vilket block du tittar på, måste du lägga till en ny parameter till var och en av dessa funktionssamtal och ställa in den 1 så att det kommer att kontrollera om blocket det ser på är starten på en grupp.
Din FindMatches funktionen ska nu se ut så här, och jag har markerat de två ändrade uttalandena för din bekvämlighet:
Nu när vi berättar CheckMatches när det behövs för att utföra denna nya kontroll måste vi faktiskt lägga till den nya kontrollen för att den ska utföra. Gå till din CheckMatches funktion och lägg till den här nya delhändelsen som första delhändelse:
Händelse: Blockera> Jämför X Comaprison = Lika till X = Function.Param (0) - ((Block.Width + 2) * Function.Param (3)) Skick: Block> Jämför Y Comaprison = Jämställt Y = Function.Param (1) - ((Block.Width + 2) * Function.Param (4)) Skick: Funktion> Jämför parameter Index = 5 Jämförelse = Likvärdig till värde = 1
Innan du avslutar modifiera CheckMatches funktion måste du också lägga till ett annat uttalande till toppen av den ursprungliga händelsen för CheckMatches funktionen, och du måste lägga till den nya parametern i CheckMatches funktionssamtal och ställa in det 0.
Den nya koden för CheckMatches-funktionen ska se ut så här:
Händelsen vi lagt till gör exakt vad jag beskrev ovan. Först tittar det på blocket ovanför, eller till vänster om, det inledande blocket du passerar in.
Om det blocket är samma färg som det du passerade in gör det ingenting eftersom det vet att blocket du passerade inte är det första blocket i den gruppen.
Å andra sidan, om det är inte samma färg som blocket du passerade in, den ursprungliga kontrollen sker på grund av det Else-uttalandet vi just lagt till, och det söker en grupp med tre eller flera block som det normalt skulle.
Om du testar spelet på denna punkt och gör en grupp med mer än tre kvarter, bör du bara se ett flytande textobjekt som berättar hur många poäng den gruppen var värd.
Nu när vi har slutat fixa alla dessa funktioner, och vi har slutfört vårt matchande system, är vi redo att genomföra rörelsessystemet. Eftersom vi redan har gjort mycket i denna handledning och eftersom rörelsessystemet kräver att vi gör flera komplexa system, ska jag vänta tills nästa artikel börjar starta rörelsessystemet.
Om du är angelägen om att börja arbeta med det, överväga några av dessa saker. Självklart är det första du behöver göra för att genomföra själva rörelsen. För det, försök att använda ett liknande system till vad vi använde när punktpunkterna flyttades. Därifrån, börja överväga hur du skulle ändra hastigheten som de rör sig om. Slutligen, hur kommer du att generera nya rader med Block för spelaren, och hur kommer du att veta det när att generera nya rader?
Ta dig tid att överväga dessa saker, och jag kommer se dig tillbaka här nästa vecka för nästa stora avdrag av serien.
