Velkommen til den femte delen av Endless Runner-serien! Opp til dette punktet bør vi ha et lite monster som kjører på en uendelig rullende plattform. Vi bør ha tre nivåer av parallaxrulling, samspill mellom vårt monster-sprite og bakken, samt evnen til å få ham til å hoppe via berøringsinteraksjon. Så dagens skritt vil gi brukerne litt utfordring: I stedet for bare å kjøre på flatt bakke, vil det være nivåendringer og groper de må hoppe over for å kunne fortsette å spille.
Vi vil oppnå denne morsomme utfordringen ved å legge til et "arrangementssystem". Dette bør ikke forveksles med de innebygde hendelsene som Corona SDK bruker. For vårt formål er ordet «event» ganske enkelt en enkel måte å forklare hva som skjer. Denne opplæringen vil bruke samme format som den siste. I nedlastingsfilen finner du to mapper: 'gammel' og 'ny'. Hvis du ikke har fulgt de andre opplæringsprogrammene og bare vil hoppe rett inn i denne, kan du bare åpne den gamle mappen og den vil ha alle filene du trenger for å komme i gang. Den nye mappen vil inneholde det ferdige prosjektet, så hvis du vil se hva alt ser ut på slutten, vær så snill å ta en topp.
Du kan kanskje gjenkjenne ordet «event» fra de tidligere opplæringsprogrammene. Se for eksempel på funksjonen som er berørt:
funksjon berørt (hendelse) hvis (event.phase == "startet") så hvis (event.x < 241) then if(onGround) then monster.accel = monster.accel + 20 end end end end
I den funksjonen brukte vi ordet «arrangement» for å bare beskrive hva som skjedde. Vi kunne veldig godt ha brukt følgende kode:
funksjon berørt (kapow) hvis (kapow.phase == "startet") så hvis (kapow.x < 241) then if(onGround) then monster.accel = monster.accel + 20 end end end end
'Event' eller 'kapow' er bare variabler som vi bruker. 'Event' skjer bare for å være mer beskrivende enn 'kapow.' Så når vi sier "arrangement" snakker vi ikke om en variabel som beskriver noe som skjer (som vist i forrige eksempel), men vi bruker ordet som en måte å beskrive et system som styrer strømmen av spillet . Du lurer kanskje på hva dette "hendelsessystemet" kan kontrollere. Vel, hvor mye moro er vår demo akkurat nå? Er det noe du vil prøve å selge? Enda viktigere er det noe som noen vil ønske å spille? Svaret er en smertefull nei, fordi kjører og hopper uten hindringer er kjedelig.
For å gjøre spillet mer interessant må vi legge til funksjoner. Ting som grunnskiftende nivåer, groper, hindringer, skurker, etc., vil gjøre spillet mye mer interessant. Men i et spill som Endless Runner kan vi ikke ha de samme hindringene som vises samtidig i hvert spill. Vi må ha alt randomisert. Det er det som gjør disse spillene så vanedannende. Så, her er vårt "arrangementssystem" virkelig skinner. I denne opplæringen skal vi diskutere hvordan man lager to forskjellige hendelser: først, grunnendringsnivåene opp og ned, og andre, skape et grop. Disse hendelsene vil bli tilfeldig generert med tilfeldige intervaller. Det er flere måter du kan gjøre om å gjøre dette. For dette eksempelet, er den mest logiske måten å sjekke om vi må starte en ny hendelse hver gang vi flytter en av våre bakkenheter tilbake til høyre side av skjermen. La oss gå videre og se på hva vi trenger for å gjøre dette.
Gå videre og åpne main.lua-filen i den gamle mappen, og vi begynner å gjøre noen endringer. Det første du må gjøre er å legge til noen variabler som vi vil bruke gjennom hele programmet. Legg til disse linjene øverst på filen rett under krev sprite-linjen:
--Disse to variablene vil være kontrollene som styrer vårt arrangementssystem. lokal inEvent = 0 lokal eventRun = 0
Deretter går du til updateSpeed-funksjonen og endrer hastigheten. Vi bør velge en langsom, gradvis, økning i fart slik at spillet faktisk utvikler seg som du forventer. Endre linjen til dette:
--Dette vil drastisk redusere hvor raskt flisene akselererer. --juster dette nummeret for å få spillhastigheten nærmere hva som fungerer for spillet ditt. fart = hastighet + .0005
Den neste tingen vi skal gjøre er å legge til vår første begivenhet. Vår første begivenhet skal gjøre hver av blokkene skifte til en nyjustert høyde hver gang en flyttes til motsatt side av skjermen. Dette vil selvfølgelig gjøres tilfeldig, slik at vårt spill alltid er nytt og spennende. For å få vårt arrangementssystem startet, må du først endre funksjonsoppdateringeneBlock () for å se slik ut:
funksjonsoppdateringBlokker () for a = 1, blokker.numHolder, 1 gjør om (a> 1) og newX = (blokker [a - 1]). x + 79 annet newX = (blokker [8]). x + 79 - hastighets ende hvis ((blokkene [a]). x < -40) then (blocks[a]).x, (blocks[a]).y = newX, groundLevel checkEvent() else (blocks[a]):translate(speed * -1, 0) end end end
Den første linjen ville ganske enkelt sette y-posisjonen til blokken for å være den samme som før det var en flat løpebane som vi har sett så langt. Den andre endrer y-posisjonen til å være det som grunnlaget er. Det variable bakkenivået vil bli tilfeldig endret i små intervaller i følgende funksjoner. Gå videre og legg til disse funksjonene hvor som helst under oppdateringsfunksjonen.
funksjonskontrollventil () - først kontroller for å se om vi allerede er i en hendelse, vi vil bare ha 1 hendelse på gang om (eventRun> 0) da - hvis vi er i en hendelse, reduseres eventRun. eventRun er en variabel som forteller oss hvordan - mye lenger hendelsen skal finne sted. Hver gang vi sjekker må vi redusere - et. Da er det nå på dette tidspunktetRun er 0, så er arrangementet avsluttet, så vi stiller inEvent tilbake - til 0. eventRun = eventRun - 1 hvis (eventRun == 0) deretter inEvent = 0 slutten - hvis vi er i en hendelse da gjør ingenting hvis (inEvent> 0 og eventRun> 0) then - ikke noe annet - hvis vi ikke er i en hendelse, sjekk for å se om vi skal starte en ny begivenhet. For å gjøre dette - Vi genererer et tilfeldig tall mellom 1 og 100. Vi sjekker deretter for å se om "sjekken" er - for å starte en hendelse. Vi bruker 100 her i eksemplet fordi det er lett å bestemme - sannsynligheten for at en hendelse vil brenne (vi kunne like enkelt valgt 10 eller 1000). - For eksempel, hvis vi bestemmer oss for at en hendelse skal - starter hver gang sjekken er over 80 da vet vi at hver gang en blokk tilbakestilles, er det en 20% sjanse for at en hendelse starter. Så en i hver fem blokker bør starte en ny begivenhet. Dette - er hvor du må passe behovene til spillet ditt. sjekk = math.random (100) - denne første hendelsen kommer til å føre til at hevingen av bakken skifter. For dette spillet vil vi - bare at høyden skal skifte en blokk om gangen, slik at vi ikke får lange endringer i forløp - det er umulig å passere, så vi setter begivenheten til 1. hvis (sjekk> 80 og sjekk < 99) then --since we are in an event we need to decide what we want to do. By making inEvent another --random number we can now randomly choose which direction we want the elevation to change. inEvent = math.random(10) eventRun = 1 end end --if we are in an event call runEvent to figure out if anything special needs to be done if(inEvent > 0) så runEvent () slutten - denne funksjonen er ganske enkel, det kontrollerer bare for å se hvilken hendelse som skal skje, da - oppdaterer de aktuelle elementene. Legg merke til at vi sjekker for å sikre at bakken ligger innenfor et bestemt område, vi vil ikke at bakken skal gyte over eller under som er synlig på skjermen. funksjon runEvent () hvis (inEvent < 6) then groundLevel = groundLevel + 40 end if(inEvent > 5 og inEvent < 11) then groundLevel = groundLevel - 40 end if(groundLevel < groundMax) then groundLevel = groundMax end if(groundLevel > groundMin) da groundLevel = groundMin slutten
Den første funksjonskontrollventilen vil bli kalt hver gang vi tilbakestiller plasseringen av blokken. Så, fortsett og ring checkEvent () rett etter linjen vi redigerte i updateBlocks (). Hver gang checkEvent () heter, kontrollerer vi for å se om vi må starte en hendelse eller ikke. Det vil også sjekke for å se om en hendelse allerede er i gang. Dette vil hjelpe oss med å kontrollere våre atferd, slik at vi ikke får for mange gale hendelser som gyter på en gang. Kjør dette, og du bør nå ha et spill som er mye morsommere å spille!
Legg merke til at hvis du kommer inn i en vegg, dør du ikke; du stopper bare. Dette er tilstrekkelig for nå. Bare husk at når du dør, eller når du vil starte simulatoren, må du bare trykke på kontroll eller kommando R, og nivået vil øyeblikkelig starte på nytt.
Du kan nå se hvordan vi lager hendelser for å kontrollere strømmen av spillet. Nå skal vi legge til en annen begivenhet, men denne gangen skal vi ikke bruke runEvent for å gjøre endringene våre. Vi skal legge til en grop som spilleren må hoppe over for å fortsette å spille. Dette kan legges ganske raskt, så la oss komme på jobb!
Den første tingen å gjøre her er å legge til en annen sjekk i funksjonen checkEvent (). Legg til denne delen rett under den andre sjekken i det samme hvis / annet setning:
hvis (sjekk> 98) så inEvent = 11 eventRun = 2 end
Deretter går du til updateBlocks () -funksjonen og endrer delen som ser slik ut:
if ((blokkene [a]). x < -40) then (blocks[a]).x, (blocks[a]).y = newX, groundLevel checkEvent() else (blocks[a]):translate(speed * -1, 0) end
Gjør det slikt:
if ((blokkene [a]). x < -40) then if(inEvent == 11) then (blocks[a]).x, (blocks[a]).y = newX, 600 else (blocks[a]).x, (blocks[a]).y = newX, groundLevel end checkEvent() else (blocks[a]):translate(speed * -1, 0) end
Etter å ha kjørt det, bør du ha en andre begivenhet i spillet som kan tilfeldigvis gyte gropen!
Legg merke til at i stedet for å definere handlingen som vil skje inne i runEvent-funksjonen, gjør vi det direkte inne i updateBlock () -funksjonen. Dette er grunnen til at arrangementssystemer som dette er nyttige. Det lar oss enkelt definere hendelser og oppdatere spillet i områdene av vår kode som gir oss mest mening. Forhåpentligvis gir dette deg en ide om hva du kan gjøre med hendelser. Ha det gøy å leke med dem og gjøre spillet fullt av interessante arrangementer. I neste veiledning legger vi til to hendelser for å holde spillet utfordrende: dårlige monstre og destruerbare hindringer! Så still inn neste gang, og hvis du har noen spørsmål, vennligst gi meg beskjed i kommentarene.