Forstå spillet Loop

Understanding Game Loop - Basix
en
Del
en
Del

Dette Cyber ​​mandag Envato Tuts + kurs vil bli redusert til bare $ 3. Ikke gå glipp av.

Nesten alle spill kan betraktes som å ha en hovedfunksjon som inneholder alt spillet logikk, og som drives enten når brukeren gjør noe, eller etter en viss tid. Denne syklusen av å kjøre den samme kjernefunksjon om og om igjen kalles game sløyfe
, og er avgjørende for å forstå for noen form for spillutvikling.


Du har sikkert spilt brettspillet Chutes og leidere (eller Snakes and Ladders som vi kaller det i Storbritannia).

(Foto credit incurable_hippie på Flickr)

Hver spiller kaster terningen (eller spinn spinneren) og beveger seg fremover antall ruter som er angitt. Torget de lander på kan henvise dem til å gli bakover eller klatre fremover flere områder. Spilleren vinner spillet når de kommer til finalen torget

Så, i bilde, landing på torget 6 gjør du klatre fire rutene til Square 10.; landing på torget 19 gjør du skyver tilbake 15 rutene til Square 4; og landing på torget 64 betyr at du vinne spillet.

Nå antar du spiller single player, for å øve. Du gjør det samme som ovenfor, om og om igjen, til du kommer til torget 64. Hvordan vil du representere dette i koden?

Du vil sannsynligvis begynne med å lage en matrise for å lagre verdiene av rutene. De fleste elementene vil inneholde null, men noen vil inneholde enten et positivt tall (som indikerer en stige), eller et negativt tall:

Merk: Dette er pseudokode, ikke AS3
Var specialSquares: Array = []; specialSquares [0] = 0; //torget spillerne starte på, før 1specialSquares [1] = 0; ... specialSquares [6] = 4; ... specialSquares [19] = -15;

... og så videre. Deretter vil du ha en funksjon for å flytte spilleren basert på antall på terningen:
funksjon movePlayer (firkanter: Number) {newSquare = currentSquare + firkanter; newSquare + = specialSquares [newSquare]; currentSquare = newSquare;}

Du kan deretter sette dette i en større funksjon som representerer en hel sving:
funksjon takeATurn () {diceNumber = tilfeldig (1, 6); //tilfeldig tall mellom 1 og 6 movePlayer (diceNumber); if (currentSquare == 64) {//spiller har vunnet! game over}}

Denne funksjonen, takeATurn (), omslutter kjernen spillet logikk for single-player Chutes og leidere. Men hvordan kan vi faktisk få denne funksjonen til å kjøre? Det finnes flere alternativer:



Kjør Funksjon Basert på Spiller Input

Vi kan plassere en knapp på skjermen, og ha den ringe takeATurn () hver gang det klikkes. Hvis du noensinne har spilt Facebook Scrabble eller Words With Friends, har du sett denne muligheten i aksjon.



Kjør Funksjon Basert på tiden gikk

Vi kan gjøre takeATurn () kjører hver seksti sekunder.

Egentlig er dette alternativet litt mer komplisert enn det kan virke. I praksis ser vi aldri noen spill uten noen
spiller innspill; uten interaksjon, kan det egentlig ikke bli vurdert et spill. Men likevel, noen spill har et element av "kalender tid" involvert. Tenk Farmville: du, spilleren, plante avlinger, og deretter hver noen minutter (eller timer) de utvikler litt videre, fra frø til skudd til frukt. Og i noen moduser av Civilization, får du en viss tid (si fem minutter) for å gjøre alle dine trekk for en "tur"; når disse fem minutter er opp, er kjernen spillet logikk funksjon utløst



Gjør Begge

Noen spill bruker en blanding av disse to alternativene. for eksempel, har Mafia Wars en ressurs kalt "energi" som påfyll en enhet hvert femte minutt; du utføre handlinger i spillet ved hjelp av denne ressursen, så kjernen spillet logikk funksjonen er fortsatt utløst av en brukerhandling, det er bare begrenset av tid

Dette er et mønster som er felles for de fleste spill. ett stykke kode inneholdende kjernelogikken spillet utløses gjentatte ganger. Vi kaller dette game sløyfe

Det er et begrep for handlingen eller tidsrom som utløser kjernen spillet logikk kode i tillegg: a. tick
(som høres en klokke gjør).

Så i Civilization, er flåtten hvert femte minutt. I Words With Friends, spille din tur fører
en hake. Med andre ord, går spillet sløyfe en gang per tick.



Hva med Mario?

Super Mario Bros ser ikke ut til å passe inn i en av disse kategoriene. Mario reagerer på spillerens innspill ... og likevel alle slags ting skjer uten at du trenger å gjøre noe (Goombaer gå rundt, teller timeren ned, gjenstander faller). Er det to
spillet sløyfer?

Nei. Det er bare ett, og det er utløst utelukkende av tid -., Men med en hake av bare en brøkdel av et sekund

I Civilization, har du en periode på fem minutter å legge inn alt du vil gjøre i den nåværende snu, før spillet "ticks" og kjører spillet loopen igjen basert på alle dine innspill. Så hvis du sier, i Turn 23, som du vil at krigere til å angripe en hjort, så i Turn 24 alle begynner å bli vilt til middag.

Det er det samme med Mario. Hvis du trykker på Gå-knappen under ett tikk, deretter i neste iterasjon av spillet loop, Mario vil begynne å hoppe.

Merk at du ikke
har å tid Jump presse å skje akkurat som kjernen spillet logikk funksjon utløses -. alle dine handlinger under en hake periode blir registrert og brukt i løpet av neste iterasjon av spillet sløyfe



er Alt
Kontrollert Gjennom spillet Loop?

Alt av spillet logikk håndteres i spillet loop. Men det er mer til et spill enn sin logikk, grafikk som er den største eksempel.

Tegne grafikk til skjermen er hardt arbeid for datamaskinen. La oss anta at du har fått et actionspill med en hake på 1 /60th av et sekund; som skal gjøre spillet føles som det er å reagere fluidly til spillerens kontroller. Men hva skjer hvis spillerens datamaskin er for treg til å kjøre all koden for spillet logikk (reagerer på inndata, simulere gravitasjon, kjører AI rutiner) og
trekke alt til skjermen innen 1 /60th av et sekund ?

I dette scenariet, kan vi bruke to separate sløyfer: et spill sløyfe og en trekke sløyfe
. Vi kunne deretter kjøre uavgjort sløyfe på en mye lavere frekvens enn spillet sløyfe; la oss si vi oppdatere skjermbildet halvparten så ofte, dvs. hver 1 /30th av et sekund.

Hvor mye prosessorkraft som kreves av spillet kan variere fra nivå til nivå. Vurdere en shoot-'em-up: de første nivåene vil ha svært få skip på skjermen, for å lette spilleren i forsiktig, mens de siste nivåene kan ha dusinvis av fiendtlige skip og hundrevis av kuler alle flyr rundt samme scene på en gang. Spillet sløyfe må finne ut hvordan alle disse objektene skal flytte, og uavgjort løkken har å gjengi hver enkelt, så selv om det kan ha vært mulig å kjøre både spillet sløyfe og uavgjort sløyfe hver 1 /60th av et sekund på start av spillet, på slutten har noe å gi.

Det er som regel enklere å bremse ned trekningen sløyfe enn spillet loop, hvis du må velge. Justere spillet sløyfe tick lengde midler justere alt i spillet som er basert på tid; hvis Mario kjører med en hastighet på 20 piksler /sekund, og du designe spillet med en hake lengde på 1 /60th av et sekund, så må du flytte ham 1 /3rd av en piksel per tick. Hvis du justerer spillet sløyfe å ha en hake lengde på 1 /30th av et sekund, så må man justere denne til 2/3-deler av en piksel per tick - og selv det er en enkel endring i forhold til å holde fysikkberegninger og AI rutiner konsekvent.

På grunn av dette, spill ofte tar sikte på å holde spillet loop tick konsekvent, og tregere trekningen sløyfe hvis mer kraft er nødvendig. Hvis du noen gang har slått på FPS telleren (forkortelse for Frames Per Second, antall ganger trekningen loopen kjører per sekund) i et førstepersons skytespill, vil du har sett det endre seg avhengig av hvor mye som er på skjermen; trekningen sløyfe oppdateringshastighet blir justert automatisk. Spillet kan se juddery - som en live streaming video på en treg internettforbindelse - men med mindre det blir kjørt på en datamaskin med en mye mindre strøm enn de spillutviklerne hadde i tankene, vil alle objekter i spillverdenen fortsette å flytte og samhandle på de riktige hastigheter.

For en stor artikkel som forklarer hvordan Flash omhandler dette, sjekk ut Sean Christ innlegg på den "Elastic Racetrack". Anmeldelser