Tekniske hemmeligheter bak 'Cosmonious High's' rollebesetning av interaktive karakterer

Comonious High inneholder 18 karakterer fordelt på seks arter, alle skapt av et team med null dedikerte animatører. Det betyr massevis av kode for å skape realistisk atferd og interaktivitet i Owlchemy-kvalitet! "Tegnsystemet" i Comonious High er en gruppe på rundt 150 manus som til sammen svarer på mange design- og animasjonsproblemer knyttet til karakterer. Enten det er hvordan de beveger seg rundt, ser på ting, samhandler med objekter eller reagerer på spilleren, er det hele svært modulært og nesten fullstendig prosedyremessig.

Denne modulariteten gjorde det mulig for et team av innholdsdesignere å lage og animere hver eneste dialoglinje i spillet, og for karakterene å føle seg levende og engasjerende selv når de ikke var midt i en samtale. Slik fungerer det.

Gjesteartikkel av Sean Flanagan og Emma Atkinson

Comonious High er et spill fra veteran VR studio Owlchemy labs om å gå på en fremmed videregående skole som definitivt er helt fri for funksjonsfeil! Sean Flanagan, en av Owlchemys tekniske artister, skapte Cosmonious Highs kjernekaraktersystem blant mange andre bestrebelser. Emma Atkinson er en del av Content Engineering-teamet, som er kollektivt ansvarlig for å implementere hver narrative sekvens du ser og hører gjennom spillet.

Kodesiden

Nesten all kode i tegnsystemet kan gjenbrukes og deles mellom alle artene. Karakterene i Comonious High er litt som modulære dukker – bygget med mange av de samme delene under, men med unik kunst og innhold på toppen som individualiserer dem.

Helt fra toppen kan tegnsystemkoden deles inn i moduler og drivere.

Moduler

Hver karakter i Comonious High får sin oppførsel fra sitt sett av tegnmoduler. Hver karaktermodul er ansvarlig for et spesifikt problemdomene, som å bevege seg eller snakke. I kode betyr dette at hver type karakter er definert av modulene vi tilordner den. Det kreves ikke karakterer for å implementere hver modul på samme måte, eller i det hele tatt (f.eks. kan ikke intercomet vinke.)

Noen av våre mest brukte moduler var:

Karakterbevegelse – Ansvarlig for bevegelse. Den spesifiserer bevegelsesatferden på høyt nivå som er felles for alle karakterer. Selve bevegelsen kommer fra hver implementering. Alle de "jordete" karakterene – Bipid og Flan – bruker CharacterNavLocomotion, som flytter dem rundt på scenen Nav Mesh.

KarakterPersonlighet – Ansvarlig for hvordan karakterer reagerer på spilleren. Denne modulen har én fot i innholdsdesign – dens hovedansvar er å huse responsene karakterene får når spillere vinker til dem, sammen med eventuelle samtalealternativer. Den inneholder også noen få "auto"-svar som er vanlige på tvers av rollebesetningen, som automatisk mottak (fanger alt du kaster) og automatisk blikk (tilbakevendende øyekontakt).

KarakterFølelse – Holder styr på karakterens nåværende følelser. Andre komponenter kan legge til og fjerne følelsesforespørsler fra en intern stabel.

CharacterVision – Holder oversikt over karakterens nåværende synsmål. Andre komponenter kan legge til og fjerne visjonsforespørsler fra en intern stabel.

Karaktertale – Hvordan karakterer snakker. Denne modulen har grensesnitt med Seret, vårt interne dialogverktøy, direkte for å sette i kø og spille av VO-lydklipp, inkludert tilhørende bildetekster. Den avslører noen få hendelser for VO-avspilling, avbrudd, fullføring, etc.

Det er viktig å merke seg at animasjon er en egen bekymring. Emotion-modulen får ikke en karakter til å smile, og Vision-modulen snur ikke hodet til en karakter – de lagrer bare karakterens nåværende følelser og visjonsmål. Animasjonsskript referanse disse modulene og er ansvarlige for å transformere dataene deres til en synlig ytelse.

Drivere

Modulene som en karakter bruker kollektivt, skisserer hva den karakteren kan gjøre, og kan til og med implementere den atferden hvis den er universell nok (som tale og personlighet.) Imidlertid er flertallet av karakteratferden ikke fangelig på et så høyt nivå. Det skitne arbeidet blir overlevert til andre manus - samlet kjent som sjåfører—som danner det virkelige ‘kjøttet’ til karaktersystemet.

Til tross for deres mer begrensede fokus, er drivere fortsatt skrevet for å være så gjenbrukbare som mulig. Noen av de viktigste driverne – som CharacterHead og CharacterLimb – representerer usynlig en del av et tegn på en måte som er atskilt fra enhver spesifikk karaktertype. Når du tar tak i hodet til en karakter med Telekinesis, får en karakter til å kaste noe eller ber en karakter spille et mocap-klipp, gjør de to skriptene det faktiske arbeidet med å flytte og rotere hver frame etter behov.

Drivere kan deles løst inn i logiske drivere og animasjonsdrivere.

Logiske drivere er som hode og lem – de gjør ikke noe synlig selv, men de fanger opp og utfører en gjenbrukbar del av karakterens oppførsel og avslører all viktig informasjon. Drivere for animasjon referanse logiske drivere og bruke dataene deres til å lage karakteranimasjoner – bevege bein, bytte masker, løse IK, etc.

Animasjonsdrivere har også en tendens til å være mer spesifikke for hver karaktertype. For eksempel bruker alle med øyne noen få forekomster av CharacterEye (en logisk driver), men en Bipid animerer faktisk øyenskyggeren deres med BipedAnimationEyes, en Flan med FlanAnimationEyes, osv. Å dele jobben med "et øye" i to deler som dette gjør det mulig for unik animasjon per art som alle støttes av samme logikk.

Fortsett på side 2: Innholdssiden »