Synka gameplay-kod med animerings/visualiserings-kod

[sirGustav]

Det är ganska dött här, så jag tänkte se om det går att få igång en diskussion om ett ämne som jag har stört mig på ett bra tag nu. Hur skall man synka gameplay-tillstånd med animering/visualiserings-tillstånd?
När jag gjorde fps var det enkelt. Så länge jag spelade upp en vettig animation så spelade inte det så stor roll, eftersom det inte fanns så många speglar och fienderna rörde sig inte mer än åt ett håll.
När jag gick över till 3rd-person och side-scrollers så började jag med en enum. Det är dock en hel del problem med att få det se bra ut. Foot-skating och ljud och andra effekter som inte är i-synk med animationen. Att komma fram till att 0.039f sekunder in i animationen skall ett ljud spelas och om karaktären rör sig 15.3f enheter i sekunden så ser det inte skit ut, och dessa värdena kommer oftast till genom att man gissar och testar sig fram.
Att komma fram till dessa enum-states som karaktären kan vara i, resulterar oftast i en hög med nästlade if-satser och förutom i de mest triviala fall så är den ganska grötig.

Den vettigaste lösningen på att synka ljud och händelser till animationen, som jag kommit på, är att markera händelser i dess time-line och på samma sätt animera en förflyttningsvektor. Problemet då är att det ställs högre krav på att animationerna synkas på rätt sätt, och där har jag ingen smart lösning. Det närmaste jag har kommit är ett tool där jag kan rita upp en fsm:er som bestämmer animation samt gameplay, men då har jag problemet hur jag skall hantera mouse-look och liknande varierande indata.

Hur brukar ni göra/någon som har någon bra idé?

[Mattias Gustavsson]

Att komma fram till dessa enum-states som karaktären kan vara i, resulterar oftast i en hög med nästlade if-satser och förutom i de mest triviala fall så är den ganska grötig.

Jo, det blir alltid en massa specialfall att hantera - det är ofrånkomligt, ligger i dess natur. Man kan ju försöka arbeta strukturerat och kanske återanvända vissa delar, men att göra nån slags generell lösning är nog ingen idé - nästa spel man försöker använda den till kommer att ha andra krav som ändå kräver sina speciallösningar, och man måste gå in och modifiera systemet.

Den vettigaste lösningen på att synka ljud och händelser till animationen, som jag kommit på, är att markera händelser i dess time-line

Vi gjorde nåt liknande i crackdown, så att grafikerna kunde markera, i modelleringsprogrammet, vissa keyframes med en textsträng, som angav ett "event" som kunde läsas av motorn. T.ex. ett "footstep" event på den keyframe där foten sattes ned. Och sånt är ju exempel på bra generella saker som man kan återanvända - men exakt hur animationer kombineras och övergår från en till en annan, det brukar vara väldigt spel-specifikt, så det bästa man kan hoppas på är att ha ett animations-system som är lätt att arbeta med och modifiera för de specifika behov man har för varje spel.

[Hildenborg]

Av någon anledning, så har jag mycket sällan varit inblandad i ljudet i de spel jag jobbat på. Så jag har tyvärr ingen erfarenhet bakom mig att tillgå på just detta.
Men jag har hunnit fundera en del på det ändå. Och den lösningen jag hade försökt mig på är i princip samma som Mattias föreslår.
Att den som skapar animationerna kan markera var i animationen ett visst ljud skall spelas upp.
Fast, sen måste man ju även inse, att även om animatören markerar ett ljud på en viss frame, så är det kanske ljudets höjdpunkt som skall spelas då. Vilket gör att personen som skapar ljudeffekten på något sätt måste ange hur många millisekunder in i samplingen som skall matcha animeringsmarkeringen.
Och till slut, en sak man inte får glömma bort, är ju att ljudeffekter alltid mixas ihop i en mindre dubbelbuffrad ljudbuffert (om man inte har ett skithäftigt ljudkort). Vilket innebär, att om bufferten är på 0.2 sekunders fördröjning, så kan det bli knepigt att tajma in ljudet oavsett hur man än gör... Man måste så att säga försöka se in i framtiden...

I slutändan, så tror jag att man kan hoppas på att få ljudet att tajma rätt i 98% av fallen, och att det får kanske duga.

Mattias:
Har du jobbat med Crackdown? Skitbra spel! Bra jobbat!
Enda missnöjet med spelet, var att jag varvade det för fort...
Väntar med spänning på tvåan. Fast det blir kanske inte så bra om inte du är inblandad denna gången?

[TheSpaceMan]

Det jag har velat testa men aldrig fått möjlighet till är att sätta fasta tidsramer till en animatör med. Jag vill normalisera alla mindre animationer till fasta enheter eller sträckor.

Dvs oavsätt om det är gång eller sprint så är det anpassat att karaktären flyttar sig en meter på motsvarande 2-3 sekunder. Sedan får man skala animationen där efter. Antaligen ett mattematiskt antal steg som ska tas med. Då kan man spela ljud och ovstånd baserat på multiplikationer. Tror dock animatören skulle hata det. Men ja så tror jag att jag skulle vilja ha det. Då går det skala spring hastigheten och lättare med och ljud och animation skulle anpassa sig.

Dock den vanligaste svaret man får av en grafiker när man försöker göra sådana saker entliga oavsätt om det gäller animationer eller delade skelett i karaktärer eller utbytbara delar är dock

Men det ser ju bajs ut.

[sirGustav]

Mattias:
Självklart går det inte skriva ett system som passar in på allt, men systemet jag hade i tankarna passar in på alla de 3rd-persons system jag har testat(implementerat i tankarna) det mot, dvs code one - use on all 3rd person games . Är det inte detta du menar, så skulle jag gärna vilja höra varför det inte skulle gå, så kan jag förklara varför jag skulle tro att det går.
Jag kan förresten tillägga att det inte är bara är knapptryckningar som fsm:en är tänkt att reagera mot, utan även externa händelser som CoverInFront, WaterBelowWaist etc. och dessa implementeras genom kod.

Hildenborg:
Det är inte begränsat till ljud, när skall particle-emitters skapas, när skall vi göra bullet-traces, och varifrån? etc. Tack för tipset om offset för effekter, hade inte tänkt på det...

TheSpaceMan:
utgå från flera animationer, ändra hastigheterna på animationenerna så att de matcha mål-hastigheten och interpolera mellan de som passar bäst.

[Mattias Gustavsson]

Mattias:
Har du jobbat med Crackdown? Skitbra spel! Bra jobbat!
Enda missnöjet med spelet, var att jag varvade det för fort...
Väntar med spänning på tvåan. Fast det blir kanske inte så bra om inte du är inblandad denna gången?

Japp, jobbade med det i två år (av de totalt fyra de tog), ett år som gameplay-programmerare och ett år med visual effects (shaders, siluett-outlines, vatten, bullet tracers, partikelsystem). Men man får ju inte direkt nån input i hur spelet ska vara när man jobbar på större spelprojekt, man får bara koda det man blir tillsagd... har faktiskt inte spelat det färdiga spelet själv...

gustav: det jag menar är att varje spel har sina unika krav för animationer - och även för 3rd person spel är dessa så olika mellan spel att man inte kan göra ett komplett system som passar alla. Man kan antingen göra ett grundsystem med mycket helper-funktionalitet, och som är skrivet för att vara lätt att jobba med och ändra i, och modifiera det för varje spel.

Eller, så kan man försöka göra ett så komplett system man kan, och sen anpassa sina spel efter vad systemet klarar av - men personligen tycker jag det är sämre, eftersom det blir så mycket jobb för att göra grundsystemet, och sämre resultat för de individuella spelen.

Min inställning till spel och spelmotorer, är att spelmotorn bör göra bara väldigt grundläggande funktionalitet, och att det mesta i övrigt bör skräddarsys för varje enskilt spel - det blir helt enkelt inte bra annars, eftersom man får kompromissa för mycket... i alla fall enligt min erfarenhet.

[Hildenborg]

Det är inte begränsat till ljud, när skall particle-emitters skapas, när skall vi göra bullet-traces, och varifrån? etc. Tack för tipset om offset för effekter, hade inte tänkt på det...

Kan hända att jag inte uppfattar hela problemet, men när det gäller positioner för olika events man vill koppla till en animation, så har jag tidigare löst det genom geometri dummies.
Vilket kanske varit enklare eftersom jag alltid arbetat med en egen exporter/importer för 3d modeller och animationer.
Sättet jag löst just detta på, är att den som modellerar kan lägga in objekt i modellen, vars positioner jag kan läsa ut och använda. Och då har jag haft regeln, att alla objekt i modellen som börjar på "d_" är dummy objekt, och deras geometri behöver inte exporteras, utan det är bara t.ex. positioner och animationer man är intresserad av.
På samma sätt har jag låtit grafikera modellera in kollissionsobjekt etc.

Utöver ljud, så är det väl inga andra events man vill kolla till, som är av den tidskomplexitet som ljud är? En partikel effekt startar vid en viss tidspunkt, och den kommer börja spelas upp direkt. Medans ljud behöver synkroniseras in så att det kommer rätt in i ljudbufferten lagom till det att hårdvaran spelar upp ljudet i det ögonblicket som animationen är i ett visst läge.
Den mesta timingen för effekter etc. hade jag löst med antingen script för en viss modell, eller ren C++ kod för en viss modell. Kan tyckas vara gammalmodigt, men jag inbillar mig att om man försöker sig på att göra ett generellt system, så slutar det med en massa programkod som aldrig klarar av att leva upp till flexibilliteten hos unika skript...
Så länge som skripten kan använda sig av den dummy datan som kommer ifrån modellen och animeringen i alla fall.

[sirGustav]

mattias:
Du kanske har missuppfattat mig, tanken är att slänga ihop ett fsm-verktyg där jag beskriver animationsövergångar baserat på diverse indata-händelser som knapp-tryck och externa conditions. Varje state har en till flera animationer och utför viss logik. Varje state är en (script) kod-bit som väljer själva animationen och utför logiken. Det hela kan egentligen klassas som en visualisering av enum förändringarna, och började som en extension till/generalisering av en fight-combo-editor för ett planerat ninja-gaiden liknande spel jag har haft i tankarna. Det kanske inte går, men jag ger inte upp förrän jag har sprungit in i väggen flera gånger om

hildenborg:
nu när du säger det så använde(eller tänkte jag använda..., kommer faktiskt inte ihåg) jag faktiskt ben-positioner&riktningar i mina första 3d-spel för att skapa objekt och spela ljud.