Skelettgenomgång

Det här avsnittet beskriver den grundläggande strukturen för en LightScript-integration och täcker viktiga tekniska krav, verkliga exempel, namnkonventioner och effektivitetstips. Det går igenom update-loopen, mätarbeteende, logik för effektutlösning och belyser vanliga fallgropar. Oavsett om du felsöker, bygger från grunden eller underhåller någon annans kod, betonar den här guiden tydlighet, stabilitet och prestanda som grundstandarderna för integrationer av hög kvalitet.

Grundläggande layout

Det här avsnittet ger en snabb översikt av hur man konfigurerar ett LightScript från ett underhållsperspektiv, med fokus på var problem typiskt uppstår och hur man hittar och åtgärdar buggar. Vi börjar med en kort genomgång av en idealisk LightScript-struktur för att bekanta dig med koden, sedan täcker vi felsökning och avslutar med vanliga frågor.

Det grundläggande skelettet kräver en <head>, <body> och <script>. Alla mätar- och användarkontrolldeklarationer placeras i <head>. Alla canvas-deklarationer tillhör <body>. Allt annat ska placeras i <script>-avsnittet.

<head>

<head> är en av de mest kritiska och komplexa delarna i ett LightScript. En felaktig användarkontroll eller mätare här kan orsaka kraschlooppar eller inaktivera sig själv och alla mätare som deklareras efter den.

När du skapar mätare behöver du säkerställa:

Perfekt syntax (för att undvika krascher och trasiga mätare)
Inga duplicerade mätarnamn (dubbletter skrivs över)
Inga mätare som sträcker sig utanför skärmgränserna (orsakar krascher och fel)
Inga saknade eller extra alternativ i mätare (leder till krascher)
Alla mätare inkluderar upplösningsjusteringar (säkerställer konsekvent beteende)

Vad gäller upplösningar är de vanligaste bildförhållandena:

16:9 (3840×2160, 2560×1440, 1920×1080, 1600×900, 1366×768, 1360×768, 1280×720)
16:10 (2560×1600, 1920×1200, 1680×1050, 1440×900, 1280×800)
21:9 (5120×2160, 3440×1440)

Som standard använder vi upplösningen 2560×1440.

Alla LightScripts måste stödja bildförhållandena 16:9, 16:10 och 21:9. Även om 4:3 inte utgör en betydande del av vår användarbas bör det ändå beaktas för framtida kompatibilitet.

Här är ett exempel på strukturen för en mätare med flera upplösningsinställningar:

Standardplatsen och -storleken för dina mätare gäller alla andra upplösningar inom samma bildförhållande. Om du t.ex. ursprungligen justerar dina mätare för att fungera med 1600×900 bör den mätaren fungera korrekt på alla andra 16:9-upplösningar. Det finns dock undantag. Fortnite har flera olika mätarpositioner även inom samma bildförhållande, och vissa bildförhållanden i sig kan vara vilseledande. Till exempel är 1366×768, en vanlig upplösning världen över, ofta listad som 16:9 men är inte ett äkta 16:9-förhållande, vilket inte är ovanligt. På liknande sätt stämmer ultrawide-förhållanden som 21:9 sällan med sina nominella dimensioner. I min erfarenhet som integrationsutvecklare har jag aldrig stött på en exakt 21:9-upplösning trots att de marknadsförs som sådana. På grund av detta måste varje ultrawide-upplösning skapas, testas och konfigureras individuellt.

Alla justeringar måste placeras mellan de öppnande <meta>- och stängande </meta>-taggarna, annars fungerar de inte. Om din standardmätare är baserad på 16:9 och fungerar konsekvent på de upplösningarna behöver du inte lägga till justeringar för andra 16:9-upplösningar. Du måste dock lägga till poster för varje upplösning i andra bildförhållanden (som 16:10 och 21:9), även om förhållandet är konsekvent.

Slutligen kräver alla mätare utom våra OCR-mätare ett HSL-intervall för att aktiveras. Dessa intervall kan kompliceras av faktorer som:

Transparenta UI-element
Gradienter i färgområden
Skärmförvridningseffekter
Öppning av menyer i spelet
UI-justeringar per upplösning
Handkontroll kontra tangentbordsanvändning
Videoinspelning, som kan introducera komprimeringsrelaterade pixelfel

Grundläggande instruktioner om HSL och normaliserade koordinater finns i vår utvecklardokumentation och upprepas inte här. Testning av dessa mätare diskuteras i avsnittet “Identifiera problem”, men det är viktigt att betona: mängden testning som krävs för att verifiera alla mätare perfekt beräknas som (antal mätare) × (antal upplösningsjusteringar) × (antal spellägen) × (antal spelbara karaktärer) × (längden på ett genomsnittligt spel). Det kan lätt summeras till timmar av verifiering per spel, särskilt om övningslägen eller andra lösningar inte är tillgängliga.

HÅLL DINA MÄTARE EFFEKTIVA – vår standard är perfektion.

<body>

<body>-taggen är där det faktiska canvas-elementet deklareras. Det bör alltid se mer eller mindre ut som följande exempel. Det faktiska canvas-id:t kan ändras om du vill, men se till att du hämtar det korrekt i skriptet.

Spara dig lite tid och kopiera och klistra in det här.

<script>

Fyra saker måste hända inuti den här taggen i varje integration:

Canvas hämtas och används för att skapa vår 2D-kontext.
Den initiala update-loopen anger mätarvärden och återanropar sig sedan oändligt för att underhålla dem.
Update-loopen håller användarkontrollvariablerna uppdaterade.
Mätare kör sina återanropsfunktioner när de är stabila.

Allmänt förfarande

Vi har redan konfigurerat det grundläggande kodskelettet. Nästa steg är att gå igenom körningsloopen som utlöser effekter från start till slut.

Videospelets UI visar information i form av färgade staplar, knappar, textrutor osv. SignalRGB fångar dessa data flera gånger per sekund, men den faktiska insamlingshastigheten beror i hög grad på effektiviteten i din kod. För att vara tydlig: en enda loop eller odeklarerad variabel kan bryta hela ditt skript, och till och med krascha SignalRGB. Ännu värre är att det är lätt att skriva kod som tekniskt fungerar men är så ineffektiv att den samlar in information med bara 1–2 FPS.
Varje mätare som deklareras i <head> måste vara så liten och effektiv som möjligt för att minska overhead. Gör dina beräkningar tidigt och ofta; en mätare som upptar 25 % av skärmen är aldrig effektiv. Med OCR-mätare, fånga enskilda bokstäver istället för hela ord. För hälso- och manastaplar, övervaka bara de väsentliga segmenten. HÅLL DINA MÄTARE SÅ SMÅ SOM MÖJLIGT.
Mätare fångar information som uppdateras med varje loop.
Tidigare gick vi igenom Meter-klassdefinitionen, som lagrar mätardata och utlöser ett återanrop när informationsmatrisen blir stabil. Överst i ditt skript deklarerar du alla Meters i ett block. Du kan ordna eller alfabetisera dem; bara begrav dem inte bland tusentals rader. Du behöver till slut finjustera stabilitetsvärden, och det är slöseri med tid att försöka komma ihåg var du placerade dem.
Inuti update-funktionen tar dessa mätare emot värden från skärminläsningslogik varje loop. Deras interna logik utvärderar stabilitet och utlöser, när den är stabil, sin tillhörande återanropsfunktion.
Dessa återanropsfunktioner bör deklareras i ditt skript men utanför update-funktionen. Inuti dem kontrollerar du tillståndet för dina Meter-värden (value, decreased, increased, diff) och använder dem för att avgöra om en effektanimation ska spelas. Att strukturera din kod på det här sättet, snarare än att lägga allt direkt i update-loopen, gör att vi kan bygga skalbara integrationer.

Verkligt exempel

Nu när du har den allmänna idén, går jag snabbt igenom ett verkligt exempelloop.

Jag spelar spelet League of Legends, som omger tillgängliga förmågor med en ljust gul markering.
Varje loop plockar den specifika förmågsmätaren upp den här färgen som värdet “1” eftersom den helt passerar mätarens HSL-intervall.
Det här “1” skickas till Meter-instansen som är kopplad till skärminläsningsmätaren och infogas i den Meter:ns informationsmatris.
Om alla värden i den matrisen är “1” anses den stabil och aktiverar den bifogade effektåteranropsfunktionen. Den här återanropsfunktionen aktiveras också om alla värden vore “0” eller “.1” t.ex.; allt Meter bryr sig om är stabilitet. En viktig notering är att återanropsfunktionen inte aktiveras kontinuerligt om Meter är konstant stabil vid samma värde – bara stabilitet med ett NYTT värde aktiverar återanropet.
När återanropsfunktionen körs anländer vi till några villkorskontroller – i det här fallet behöver vi bara kontrollera om Meter.value är “0”, vilket indikerar att en förmåga har använts.
Eftersom Meter value är “1” misslyckas vi i den här kontrollen och spelar inte förmågseffekten.
Flera sekunder senare aktiverar jag förmågan och den gula markeringen runt knappen försvinner.
Det nya mätarvärdet är 0, vilket skickas till dess Meter-klass.
När stabilitet nås aktiveras återanropet och vårt villkor uppfylls, vilket spelar förmågseffekten. Latens beror helt på längden på Meter-matrisen, som du anger vid deklarationen. Mer längd innebär mer latens och färre falska utlösningar, så se till att testa tills du har hittat en bra balans.

Namnkonventioner

Skärminläsningsmätare bör ha enkla, tydliga och beskrivande namn och alltid börja med en liten bokstav. Att namnge en hälsostapelmätare “healthBar” är utmärkt. Att namnge två mätare “healthBarRed” och “healthBarGreen” när de spårar olika färger i samma område är också bra. Men att namnge en liten mätare som bara dyker upp under en hjältes ultimateffekt något som “hrO21_yes” leder bara till smärta och lidande för alla andra som försöker fixa din kod. Att lista ut vad en dåligt namngiven, liten mätare spårar kan bokstavligen ta en timmes fixande på enskilda pixlar om du har otur, så gör inte det.

Meter-klass-instanser bör ha stor bokstav och sluta med ordet Meter. Exempel som “Q_Meter”, “TookDamageMeter” och “TowerDestroyedMeter” fungerar alla utmärkt. Dessa bör vara tydligt åtskiljbara från mätare som deklareras i <head>-avsnittet.

Effektfunktioner bör också namnges så enkelt och beskrivande som möjligt. Vissa spel har hundratals sådana funktioner; andra kan ha färre än tio. Om flera hjältar har unika förmågor, inkludera hjältens namn som prefix, som “SonaQ”, “ChamberE” eller “AshUlt”. I League of Legends finns t.ex. funktioner som “DragonEffect”, “TowerEffect” och “Q_Effects”, som innehåller flera villkor och används av flera mätare. Den typen av namngivning hjälper också med optimering för skala.

Stava inte fel. Om du är osäker på hur något stavas, slå upp det. Namn måste vara tydliga och läsbara, oavsett vem som arbetar med koden eller hur mycket tid som har gått. Att organisera namn alfabetiskt hjälper vid snabb uppsökning, särskilt om du redigerar det avsnittet ofta. Även om den här nivån av organisation inte krävs för att koden ska köras, gör den stor skillnad för våra underhållsutvecklare.