Snabbstart för spelutvecklare

Välkommen till snabbstartsguiden om du är spelutvecklare och letar efter ett enkelt sätt att integrera SignalRGB-effekter för dina användare. Våra utvecklare är specialiserade på att få effekter att fungera med användargränssnitt som inte är utformade för våra ändamål. Användare gillar färggradienter, genomskinliga UI, anpassningsbara förmåge-UI, studsande eller viftande HUD-element – alla inkonsekvenser som vi måste ta hänsyn till när effekter utlöses. Ju mer utmanande användargränssnittet är, desto mindre kan vi göra för spelupplevelsen och användarupplevelsen. Med ett samarbete mellan dig och våra utvecklare kan dessa problem elimineras och spelintegrationer kan tas till en ny nivå.

Grunderna för utlösning

SignalRGB:s API erbjuder unika och kraftfulla verktyg för utvecklare att analysera visuell information. Enkelt uttryckt kan vi fånga exakta RGB-färgdata från vilken pixel eller grupp av pixlar som helst och använda förändringar i stabila värden för att utlösa effekter. En sjunkande hälsobar, en öppnande meny eller en förmågesymbol vars mättnad minskar – vilket som helst konsekvent UI-element kan användas för att utlösa effekter på användarens kringutrustning.

Den här metoden betraktas som indirekt kommunikation och medför olika utmaningar som våra utvecklare tar hänsyn till i varje integration. Avsnitten nedan utforskar idéer om direkt kommunikation som för tillfället är teoretiska (spelutvecklare, kontakta oss).

Idé 1 – Binär kommunikation

Vår enklaste utlösare kontrollerar ett visst färgintervall och returnerar “ja” om det matchar, “nej” om det inte gör det. Ur ett dataperspektiv kallas det en bit, och en grupp om åtta bitar bildar en byte som kan representera upp till 256 möjliga tillstånd.

I praktiken anger du koordinaterna för fasta pixlar på skärmen (synliga i alla upplösningar). Dessa pixlar kan vara grupperade eller utspridda och kan vara i vilken färg som helst; det enda kravet är att varje pixels position aldrig förändras i spelet och att aktiveringsfargen förblir konsekvent. När en pixels färg matchar aktiveringsfargen registreras den som “1” i arrayen. När den är en annan färg registreras den som “0”. Varje bildruta beräknar integrationen det heltal som härleds från den binära arrayen och upprätthåller det relevanta tillståndet du har definierat.

Här är ett förenklat exempel med bara tre pixlar som producerar sex unika tillstånd. UI-elementet i det här exemplet är hörnet av en minimikarta i ett populärt spel.

Och mina tre pixlar:

Jag valde originalkärnorna som genomgångsfärger, så den här bitarrangemanget är lika med 111 eller “6”. Ingen av dem passerar eller 000 ger “0”.

Det första som behöver göras är att skapa ett “vilande” tillstånd i spelet som bevarar allt som pågår medan det väntar på fler indata. Det blir tillståndet “0” och kan representeras med följande pixelvärden:

Jag ställde in var och en som rgb(0, 0, 0) för att inte passera. Men så stora skillnader kan märkas av användaren. I nästa exempel ska vi vara mer försiktiga.

Så låt oss anta att vi är i spelet och upprätthåller ett grundläggande tillstånd. Din karaktär använde sin första förmåga och vi vill registrera den förändringen som en effekt. Effekten för “Förmåga 1 använd” har utsetts till tillstånd “1” och aktiveras när integrationen kommunicerar tillståndet “1”. För att göra det justerar jag de grundläggande färgerna för pixel 1 och 2 (från vänster) subtilt för att bilda 001.

Det kanske inte verkar som mycket, men pixel 1:s ljusstyrka har minskats med ungefär 30 % och pixel 2 har fått 50 % mättnad. Eftersom vårt system enkelt kan detektera dessa förändringar kommer tillståndet på ett tillförlitligt sätt att växla till “1” och förmågeeffekten utlöses. Förmågor med specifika varaktigheter kan löpa ut av sig själva, men låt oss säga att den här förmågan aktiveras med ett knapptryck och avslutas med ett annat. För att upprätthålla en obestämd effekt aktiverar tillstånd “1” den och tillstånd “2” kan avsluta den baserat på ytterligare användarindata. Vissa effekter är väldigt analytiska och måste fortfarande hanteras separat av våra utvecklare, men för resten av dem är det här systemet ett kandidat för att vara tillförlitligt. Den primära begränsningen är synligheten för de “pixlar” som måste vara fasta under speltillståndet och som förmodligen måste vara större än upplösningen för tillstånd “1”-pixeln.