Tekniske hemmeligheder bag 'Cosmonious High's' rollebesætning af interaktive karakterer

Cosmonious Høj indeholder 18 karakterer på tværs af seks arter, alle skabt af et hold med nul dedikerede animatorer. Det betyder masser af kode til at skabe realistisk adfærd og interaktivitet i Owlchemy-kvalitet! 'Karaktersystemet' i Cosmonious Høj er en gruppe på omkring 150 scripts, der tilsammen besvarer mange design- og animationsproblemer relateret til karakterer. Uanset om det er, hvordan de bevæger sig rundt, ser på ting, interagerer med objekter eller reagerer på spilleren, er det hele meget modulopbygget og næsten fuldstændigt proceduremæssigt.

Denne modularitet gjorde det muligt for et team af indholdsdesignere at skabe og animere hver eneste dialoglinje i spillet, og karaktererne kunne føle sig levende og engagerende, selv når de ikke var midt i en samtale. Sådan fungerer det.

Gæsteartikel af Sean Flanagan & Emma Atkinson

Cosmonious Høj er et spil fra veteran VR-studiet Uglekemi Labs om at gå på et fremmedgymnasium, der helt sikkert er helt fri for fejlfunktioner! Sean Flanagan, en af ​​Owlchemys tekniske kunstnere, skabte Cosmonious Highs kernekaraktersystem blandt mange andre bestræbelser. Emma Atkinson er en del af Content Engineering-teamet, som er kollektivt ansvarlige for at implementere hver narrativ sekvens, du ser og hører gennem spillet.

Kodesiden

Næsten al kode i karaktersystemet kan genbruges og deles mellem alle arterne. Karaktererne i Cosmonious Høj er lidt ligesom modulopbyggede dukker - bygget med mange af de samme dele nedenunder, men med unik kunst og indhold på toppen, der individualiserer dem.

Helt fra toppen kan tegnsystemkoden opdeles i moduler , drivere.

Moduler

Hver karakter i Cosmonious Høj får sin adfærd fra sit sæt af tegnmoduler. Hvert karaktermodul er ansvarligt for et specifikt domæne af problemer, såsom at bevæge sig eller tale. I kode betyder det, at hver type karakter er defineret af de moduler, vi tildeler den. Der kræves ikke tegn for at implementere hvert modul på samme måde eller overhovedet (f.eks. kan samtaleanlægget ikke svinge).

Nogle af vores mest brugte moduler var:

Karakterbevægelse – Ansvarlig for bevægelse. Den specificerer den bevægelsesadfærd på højt niveau, der er fælles for alle karakterer. Den faktiske bevægelse kommer fra hver implementering. Alle de 'jordede' karakterer – Bipid og Flan – bruger CharacterNavLocomotion, som flytter dem rundt på scenen Nav Mesh.

KarakterPersonlighed – Ansvarlig for hvordan karakterer reagerer på spilleren. Dette modul har én fod i indholdsdesign - dets hovedansvar er at rumme de reaktioner, karakterer har, når spillere vinker til dem, sammen med eventuelle samtalemuligheder. Den rummer også et par "auto"-svar, der er almindelige på tværs af rollebesætningen, såsom automatisk modtagelse (fanger alt, hvad du kaster) og automatisk blik (tilbagevendende øjenkontakt).

KarakterFølelse – Holder styr på karakterens aktuelle følelser. Andre komponenter kan tilføje og fjerne følelsesanmodninger fra en intern stak.

CharacterVision – Holder styr på karakterens aktuelle visionsmål. Andre komponenter kan tilføje og fjerne vision-anmodninger fra en intern stak.

Karaktertale – Hvordan karakterer taler. Dette modul har grænseflader med Seret, vores interne dialogværktøj, direkte for at sætte i kø og afspille VO-lydklip, inklusive eventuelle tilknyttede billedtekster. Den afslører nogle få begivenheder for VO-afspilning, afbrydelse, afslutning osv.

Det er vigtigt at bemærke, at animation er en separat bekymring. Emotion-modulet får ikke en karakter til at smile, og Vision-modulet drejer ikke en karakters hoved – de gemmer blot karakterens aktuelle følelser og visionsmål. Animation scripts henvisningen disse moduler og er ansvarlige for at transformere deres data til en synlig ydeevne.

Drivere

De moduler, som en karakter bruger tilsammen, skitserer, hvad den karakter kan gøre, og kan endda implementere den adfærd, hvis den er universel nok (såsom tale og personlighed). Men størstedelen af ​​karakteradfærd er ikke fangbar på et så højt niveau. Det beskidte arbejde bliver overdraget til andre manuskripter - samlet kendt som chauffører -som danner karaktersystemets egentlige 'kød'.

På trods af deres mere begrænsede fokus er drivere stadig skrevet til at være så genbrugelige som muligt. Nogle af de vigtigste drivere – som CharacterHead og CharacterLimb – repræsenterer usynligt en del af en karakter på en måde, der er adskilt fra enhver specifik karaktertype. Når du griber en karakters hoved med Telekinesis, får en karakter til at kaste noget eller beder en karakter om at spille et mocap-klip, udfører disse to scripts det faktiske arbejde med at flytte og rotere hver frame efter behov.

Drivere kan løst opdeles i logiske drivere , animationsdrivere.

Logiske drivere er som hoved og lem - de gør ikke noget synligt selv, men de fanger og udfører en genanvendelig del af karakteradfærd og afslører enhver vigtig information. Animation drivere henvisningen logiske drivere og bruge deres data til at skabe karakteranimation – bevæge knogler, bytte masker, løse IK osv.

Animationsdrivere har også en tendens til at være mere specifikke for hver karaktertype. For eksempel bruger alle med øjne nogle få forekomster af CharacterEye (en logisk driver), men en Bipid animerer faktisk deres øjenskygger med BipedAnimationEyes, en Flan med FlanAnimationEyes osv. At opdele jobbet som "et øje" i to dele som dette tillader for unik animation pr. art, der alle er understøttet af den samme logik.

Fortsæt på side 2: Indholdssiden »