Dette er en oppfølging av min første veiledning om bruk av Nintendo-metoden for nivådesign. Under opprettelsen av Super Mario World skapte designteamet på Nintendo (kanskje serendipitously) en metode for å bygge og organisere nivåinnhold. Jeg kaller denne metoden "utfordring, kadence, ferdighets tema" system eller CCST for kort.
I den forrige veiledningen definerte jeg vilkårene utfordring og cadence; hvis du ikke har lest den artikkelen, kommer denne ikke til å gi mye mening. I denne artikkelen skal jeg snakke om hvordan jeg skal bruk De primære typer utfordringer, evolusjoner og utvidelser.
Selv om CCST-strukturen er et middel til å organisere nivådesign innhold, begrenser det ikke kreativiteten til designeren på noen måte. Faktisk vil jeg vise deg hvordan CCST-strukturen hjelper designere til å få mest mulig ut av et begrenset sett med verktøy for å lage nivådesign.
Jeg har laget et nivå her som viser hvordan å produsere en rekke forskjellige (og stadig vanskeligere) utfordringer med bare seks forskjellige fiender / hindringer. Jeg refererer til dette nivået gjennom hele denne opplæringen, så ta en titt på gjennomføringen nedenfor:
Nivåkode: 1288 0000 00EC F5A2
For de første syv utfordringene i nivået skal jeg fokusere på å bruke evolusjoner. Hvis du husker fra den første artikkelen, utvikler en utfordring når det blir kvalitativt vanskeligere enn den forrige utfordringen, mens du holder den samme grunnleggende ideen.
La oss se hvordan dette fungerer på dette nivået. Her er den første utfordringen spilleren kommer over:
Det er en enkel forekomst av en Thwomp som vil falle fra taket når Mario kommer nær nok til det. Det er en veldig enkel designidee, og utviklingen av dette er også ganske enkel.
Alt jeg gjorde her var å legge til den roterende brannfellen. I stedet for å løpe rett gjennom, må spilleren nå lage et lite hopp for å komme over det.
Å legge til et nytt element i et gammelt element er trolig den mest grunnleggende formen for evolusjon. Når det er flere hindringer å tenke på, er utfordringen vanskeligere, det er en ganske enkel dynamikk, men det er også en byggestein for vanskeligere utfordringer.
For den tredje utfordringen legger jeg til et nytt element: en fallgruve bare til venstre for Thwomp.
Denne putten tvinger spilleren til å hoppe, noe som betyr at spilleren må gjøre et hopp i Thwomps brannlinje (så å si). Du vil legge merke til at dette ikke er mye vanskeligere enn den forrige utviklingen, og det skal ikke være. Begge disse utviklingene forgrener seg ganske enkelt fra den første utfordringen, men i forskjellige retninger.
Deretter presenterer jeg en evolusjon av fallgruven: en fireball skyter opp med jevne mellomrom, noe som betyr at spilleren må vente på riktig øyeblikk for å hoppe over plattformen og under Thwomp. Dette bygger klart på den forrige utfordringen, og det er litt vanskeligere, men det er fortsatt ikke så vanskelig ennå.
For den neste utfordringen legger jeg sammen alt som nivået har gjort opp til dette punktet:
Dette er den vanskeligste utfordringen så langt, fordi det har tre hindringer i det på en gang. Mesteparten av tiden er tre hindringer det største antallet du vil se i en Nintendo-utfordring. Denne utfordringen er ganske vanskelig, og omtrent like hard som de fleste Nintendo-utfordringer får. Du kan sikte mot noe vanskeligere i dine egne spill (eller dine egne Mario Maker-nivåer), men teknikken jeg bruker her er fortsatt et middel for å komme dit.
For de neste to utviklingene, slipper jeg faktisk vanskeligheten litt, og i stedet fokuserer på kvalitativ variasjon. Et spilldesignprinsipp som jeg ikke kan stresse nok er det nivåer bør ikke alltid bli vanskeligere på en lineær måte. Sværheten på de fleste nivåer går både opp og ned. Noen ganger er det nok for utfordringer å bare være annerledes, i stedet for mer og vanskeligere.
Med den tanken, for denne utviklingen, fjerner jeg gruven og erstatter den med en Chain Chomp.
Og så, for den endelige utfordringen, bringer jeg tilbake pits og fireball, men jeg slipper den roterende flammefellen.
Disse er fortsatt ganske vanskelige utfordringer, men de holder ikke designelementene oppe. Det er en grense for hvor mye ting du kan stable i dine utfordringer før utfordringen slutter å være morsom og begynner å være irriterende, selv om grensen avhenger mye av konteksten.
Før jeg kommer til den overordnede leksjonen som vi kan lære av evolusjoner, vil jeg se på riktig utvikling av ekspansjonsutfordringer. I den forrige artikkelen definerte jeg utvidelser som evolusjoner, bortsett fra at de endres kvantitativ elementer av en utfordring foran dem. La oss ta en titt på en veldig enkel utvidelse, nå.
Dette er den første utvidelsen. Vi går helt tilbake til den første utfordringen i nivået, og dobler bare antall Thwomps.
Hovedspørsmålet å spørre er "Hva er forholdet mellom numeriske økninger og oppfattet vanskeligheter?" Denne utfordringen er numerisk farligere enn dens forfedre, men til tross for at antall Thwomps blir doblet, er det ikke en stor forandring i spillerens innsatsnivå.
Dette er et viktig prinsipp for å forstå om bruk av utvidelser: vanskeligheten med en utfordring skaleres ikke lineært med utvidelser. Utvidelser er like avhengige av kontekst som evolusjoner er, til tross for at de er forskjellige i byggingen.
La oss ta en titt på en annen utvidelse.
Dobling av antall flammefeller skaper en utfordring som er betydelig vanskeligere enn doblingen av Thwomps (spesielt siden deres rotasjoner ikke synkroniseres). Faktisk er dette trolig den vanskeligste utfordringen på hele nivået. Det samme snill av utvidelse som tidligere skjer, men spillerens erfaring med det er betydelig forskjellig.
Men hva med en utvidelse med et helt annet element? Her er en utvidelse av hoppavstanden.
Dette er en litt mindre åpenbar måte å implementere utvidelser på. Jeg har økt størrelsen på gropen med to blokklengder (dobler størrelsen, akkurat som jeg doblet alt annet), noe som betyr at spilleren definitivt vil føle endringen i hoppens størrelse, selv om endringen ikke er åpenbart med et blikk.
Det interessante med denne utfordringen er at den utvidede kjøreavstanden faktisk ikke gjør utfordringen så mye vanskeligere. En del av utfordringen ved fireball-hoppene er at spilleren må vinkle Mario's nedstigning for ikke å kollidere med Thwomp.
Hoppet over større grop endrer faktisk Mario's hoppebane, slik at han kommer lenger unna den fallende Thwomp, og sikrere! Det første hoppet er fortsatt vanskeligere enn sin forfader, men den generelle utfordringen kan ikke være mye vanskeligere i det hele tatt. Dette er de tingene du må være på utkikk etter i løpet av spilltesting, hvis du bruker CCST-rammen.
Deretter går jeg tilbake til den mer åpenbare formen av fordoblet element, ved å sette inn to brannboller.
Denne utfordringen er vanskeligere enn de to Thwomps, men enklere enn de to flammefeltene. Dobling av antall brannboller skaper et litt mindre tidsvindu hvor spilleren kan hoppe gjennom utfordringen, men det er bare ikke så vanskelig som utfordringen umiddelbart før.
Takeaway-meldingen her er at selv om utvidelser er svært enkle å implementere i begynnelsen, kan de være svært vanskelig å balansere. Dobling av ett element er ikke det samme som dobling av et annet element, uansett hvor likt disse to elementene er.
Det er andre måter å bruke utvidelser på for å gjøre utfordringene vanskeligere. En metode jeg liker mye er det jeg kaller ekspansjon ved sammentrekning. Det er en oxymoronic term, men det fanger ideen godt. La oss ta en titt på en:
Det jeg har gjort her er å kontraktse mengden trygg plass mellom Mario og Thwomp. Det er tydelig en numerisk økning i vanskeligheter basert på den første utfordringen i nivået, så vi kaller det fortsatt en ekspansjon, selv om det reduserer noe. Nesten alltid blir utvidelser ved sammentrekning utført ved å redusere mellomrom mellom Mario og noen fare. Noen ganger er det gjort ved å bevege seg nærmere faren, og noen ganger gjøres det ved å redusere størrelsen på en plattform; alt avhenger av kontekst.
Den største faren i utvidelsen ved sammentrekning er å bygge opp for mye, slik at spilleren helt enkelt ikke kan komme gjennom utfordringen uten å ta skade. Min siste utfordring gjør dette: den endelige Thwomp er så nær bakken at Mario må ende opp med å bli slått av den hvis han prøver å løpe forbi dem alle.
Dette gir to svært viktige poeng om bruken av utvidelser.
Det første punktet er at det er en grense for hvor mye et designelement kan utvides numerisk. Til slutt vil gropene bli for store, fiender for mange, eller de trygge plassene er for smale. Hvis du ønsker å designe ditt nivå opp til maksimal terskel for utvidbarhet, er det sannsynligvis en god ide å designe bakover, startende fra maksimum og arbeide tilbake mot en mindre begynnelse.
Når det er sagt, den andre viktige tingen å vite om utvidelser er at noen ganger er de bare psykologiske. I den siste utfordringen jeg viste deg, kommer de tre første Thwompsene ikke til å nå Mario hvis han er i full fart, så faren er ikke så stor. Hvis spilleren kjennes som om de nettopp har gjort noe prangende og komplisert, har nivået gjort jobben sin nok.
Dette var en lang og litt svingete artikkel, så jeg vil gjerne gjenta noen av hovedpoengene her. Det overordnede punktet er at selv om det finnes klare, repeterbare strategier for å utvikle nivåinnhold, gir disse strategiene ikke helt forutsigbart innhold. Virkelig, dette er en god ting, fordi det betyr at CCST-rammeverket fremdeles tilbyr god plass til kreativitet. Rammen handler ikke om å lage malings-nivå-nivåer; Det handler om å organisere innholdet ditt slik at nivåene kan være både sammenhengende og utfordrende.
Nintendo opprettet flere spill ved hjelp av denne metoden, eller en litt modifisert versjon av den. I tillegg kommer CCST-rammen (evolusjoner og utvidelser) i mange andre typer spill, ikke bare Nintendo-titler eller plattformspillere. På slutten av dagen er denne metoden bare et middel til å organisere innholdet ditt, ikke for å endre stemmen til spillet ditt.