Gå til indhold

Hurtigstart for spiludviklere

Hvis du er spiludvikler og leder efter en enkel måde at integrere SignalRGB-effekter til dine brugere, er du velkommen til hurtigstart-vejledningen. Vores udviklere er specialiserede i at få effekter til at virke med en brugergrænseflade, der normalt ikke er beregnet til vores formål. Brugere kan lide funktioner som farvegradienter, gennemsigtige brugergrænseflader, tilpasselige færdigheds-UI’er, HUD-elementer der hopper eller vipper – alt dette er inkonsistenser som vi skal tage højde for, når vi udløser effekter. Jo sværere brugergrænsefladen er, desto mindre kan vi gøre for spillet og brugeroplevelsen. Med lidt samarbejde mellem dig og vores udviklere kan disse problemer elimineres og spilintegrationer løftes til næste niveau.

SignalRGBs API tilbyder unikke og kraftfulde værktøjer til udviklere til at analysere visuelle oplysninger. Kort sagt kan vi præcist opfange RGB-farvedata fra en hvilken som helst pixel eller gruppe af pixels og bruge ændringer i stabile værdier til at udløse effekter. For eksempel en faldende livsstang, et åbent menu eller et afmættet færdighedssymbol – ethvert konsistent UI-element kan bruges til at udløse en effekt på brugerens periferienheder.

Denne metode betragtes som indirekte kommunikation og medfører flere udfordringer som vores udviklere tager højde for ved enhver integration. De følgende afsnit undersøger idéer til direkte kommunikation, der i øjeblikket er af teoretisk karakter (spiludviklere, kontakt os).

Vores enkleste udløser kontrollerer et bestemt farveområde og returnerer “ja” hvis det matcher, eller “nej” hvis det ikke gør. I datatermer kaldes det et bit, og en gruppe af otte bits udgør en byte, der kan repræsentere op til 256 mulige tilstande.

I praksis angiver du koordinaterne for faste pixels på skærmen (synlige ved alle opløsninger). Disse pixels kan være bundtede eller spredte og have en hvilken som helst farve – så længe placeringen af hver pixel i spillet aldrig ændres, og dens aktiveringfarve forbliver konstant. Hvis en pixels farve matcher aktiveringfarven, registreres den som “1” i arrayet. Hvis den har en anden farve, registreres den som “0”. Hvert frame beregner integrationen det resulterende heltal fra denne binære sekvens og opretholder den tilsvarende tilstand du har defineret.

Her er et forenklet eksempel med kun tre pixels, der producerer seks unikke tilstande. UI-elementet i dette eksempel er hjørnet af et minimini fra et populært spil.

Og mine tre pixels:

Jeg har valgt de originale farver som aktiveringfarve, så dette bit-arrangement er lig med 111 eller “6”. Ingen pixel der matcher eller 000 ville give “0”.

Først skal vi fastlægge en “inaktiv” tilstand i spillet, der blot opretholder alt andet mens vi venter på yderligere input. Dette vil være tilstand “0” og kunne repræsenteres af følgende pixelværdier:

Jeg har sat hver til rgb(0, 0, 0), som ikke matcher. Dog kan så store forskelle være synlige for brugeren. I næste eksempel vil vi være mere subtile.

Antag at vi har fastslået at vi er i spillet og opretholder en basistilstand. Din karakter har brugt sin første færdighed, og vi ønsker at registrere denne ændring som en effekt. Effekten for “Færdighed 1 brugt” er sat som tilstand “1” og aktiveres, når vi kommunikerer tilstand “1” til vores integration. For at gøre dette redigerer jeg let basisfarverne for pixel 1 og 2 (fra venstre) for at skabe 001.

Det ser måske ikke af meget ud, men pixel 1 har sænket sin lysstyrke med ca. 30%, og pixel 2 har fået 50% mætning. Da vores system nemt kan registrere disse ændringer, skifter tilstanden pålideligt til “1” og færdighedseffekten udløses. Færdigheder med fastsatte varigheder kan afslutte sig selv, men lad os antage at denne aktiveres med et tastetryk og afsluttes med et andet. For at opretholde en ubestemt effekt ville tilstand “1” aktivere den, og tilstand “2” kunne afslutte den baseret på yderligere brugerinput. Nogle effekter er meget analoge og skal stadig håndteres individuelt af vores udviklere, men for de øvrige fremstår dette system som pålideligt. Den primære begrænsning er synligheden af “pixels”, der skal være konstante under gameplay-tilstanden og sandsynligvis bør være større end opløsningen af tilstand-”1”-pixelen.