Tekniska hemligheter bakom 'Cosmonious High's' rollbesättning av interaktiva karaktärer

Comonious High innehåller 18 karaktärer från sex arter, alla skapade av ett team med noll dedikerade animatörer. Det betyder massor av kod för att skapa realistiska beteenden och interaktivitet av Owlchemy-kvalitet! "Teckensystemet" i Comonious High är en grupp på cirka 150 manus som tillsammans svarar på många design- och animationsproblem relaterade till karaktärer. Oavsett om det handlar om hur de rör sig, tittar på saker, interagerar med föremål eller reagerar på spelaren, är allt mycket modulärt och nästan helt procedurmässigt.

Denna modularitet gjorde det möjligt för ett team av innehållsdesigners att skapa och animera varje enskild dialoglinje i spelet, och för karaktärerna att känna sig levande och engagerande även när de inte var mitt i en konversation. Så här fungerar det.

Gästartikel av Sean Flanagan & Emma Atkinson

Comonious High är ett spel från veteran VR studio Owlchemy Labs om att gå på en utomjordisk gymnasieskola som definitivt är helt fri från funktionsfel! Sean Flanagan, en av Owlchemys tekniska artister, skapade Cosmonious Highs centrala karaktärssystem bland många andra ansträngningar. Emma Atkinson är en del av Content Engineering-teamet, kollektivt ansvarigt för att implementera varje narrativ sekvens du ser och hör genom hela spelet.

Kodsidan

Nästan all kod i teckensystemet är återanvändbar och delas mellan alla arter. Karaktärerna i Comonious High är lite som modulära dockor — byggda med många av samma delar under, men med unik konst och innehåll ovanpå som individualiserar dem.

Från toppen kan teckensystemkoden delas upp i moduler och chaufförer.

Moduler

Varje karaktär i Comonious High får sitt beteende från sin uppsättning av teckenmoduler. Varje teckenmodul är ansvarig för en specifik domän av problem, som att röra sig eller prata. I kod betyder detta att varje typ av karaktär definieras av modulerna vi tilldelar den. Karaktärer krävs inte för att implementera varje modul på samma sätt eller alls (t.ex. intercom kan inte vika.)

Några av våra mest använda moduler var:

Karaktärsrörelse – Ansvarig för förflyttning. Den specificerar rörelsebeteendet på hög nivå som är gemensamt för alla karaktärer. Den faktiska rörelsen kommer från varje implementering. Alla de "jordade" karaktärerna – Bipid och Flan – använder CharacterNavLocomotion, som flyttar dem runt på scenen Nav Mesh.

KaraktärPersonlighet – Ansvarig för hur karaktärer reagerar på spelaren. Den här modulen har en fot i innehållsdesign – dess huvudsakliga ansvar är att hysa de svar karaktärerna får när spelare vinkar till dem, tillsammans med eventuella konversationsalternativ. Den innehåller också några "auto"-svar som är vanliga i skådespelarna, som automatisk mottagning (att fånga allt du kastar) och automatisk blick (återvändande ögonkontakt).

KaraktärKänslor – Håller reda på karaktärens nuvarande känslor. Andra komponenter kan lägga till och ta bort känsloförfrågningar från en intern stack.

CharacterVision – Håller reda på karaktärens nuvarande synmål. Andra komponenter kan lägga till och ta bort vision-förfrågningar från en intern stack.

Character Speech – Hur karaktärer pratar. Den här modulen samverkar med Seret, vårt interna dialogverktyg, direkt för att köa och spela upp VO-ljudklipp, inklusive tillhörande bildtexter. Det exponerar några händelser för VO-uppspelning, avbrott, slutförande, etc.

Det är viktigt att notera att animering är ett separat problem. Emotion-modulen får inte en karaktär att le, och Vision-modulen vänder inte en karaktärs huvud – de lagrar bara karaktärens nuvarande känslor och synmål. Animationsskript referens dessa moduler och ansvarar för att omvandla deras data till en synlig prestanda.

Drivrutiner

Modulerna som en karaktär använder tillsammans beskriver vad den karaktären kan göra, och kan till och med implementera det beteendet om det är tillräckligt universellt (som tal och personlighet.) Men majoriteten av karaktärsbeteendet går inte att fånga på en så hög nivå. Det smutsiga arbetet överlämnas till andra manus - gemensamt kända som förare—som utgör karaktärssystemets verkliga "kött".

Trots deras mer begränsade fokus är drivrutiner fortfarande skrivna för att vara så återanvändbara som möjligt. Några av de viktigaste drivrutinerna – som CharacterHead och CharacterLimb – representerar osynligt någon del av en karaktär på ett sätt som är skilt från någon specifik karaktärstyp. När du tar tag i en karaktärs huvud med Telekinesis, låter en karaktär kasta något eller säger åt en karaktär att spela ett mocap-klipp, gör dessa två manus själva arbetet med att flytta och rotera varje bildruta efter behov.

Förare kan löst delas in i logiska drivrutiner och animationsdrivrutiner.

Logiska drivkrafter är som huvud och lem – de gör inget synligt själva, men de fångar och utför någon återanvändbar del av karaktärens beteende och avslöjar all viktig information. Drivrutiner för animering referens logiska drivrutiner och använda deras data för att skapa karaktärsanimationer – flytta ben, byta maskor, lösa IK, etc.

Animationsdrivrutiner tenderar också att vara mer specifika för varje teckentyp. Till exempel, alla med ögon använder några få instanser av CharacterEye (en logisk drivrutin), men en Bipid animerar faktiskt deras ögonskuggare med BipedAnimationEyes, en Flan med FlanAnimationEyes, etc. Att dela upp jobbet som "ett öga" i två delar som detta tillåter för unik animering per art som alla backas upp av samma logik.

Fortsätt på sida 2: Innehållssidan »