Skeleton vodič

Ovaj odeljak opisuje osnovnu strukturu LightScript integracije i pokriva važne tehničke zahteve, primere iz prakse, konvencije imenovanja i savete za efikasnost. Vodi kroz petlju ažuriranja, ponašanje merača, logiku aktiviranja efekata i ističe uobičajene zamke. Bez obzira da li otklanjate greške, gradite od nule ili održavate tuđi kod — ovaj vodič naglašava jasnoću, stabilnost i performanse kao osnovne standarde visokokvalitetnih integracija.

Osnovna struktura

Ovaj odeljak pruža brzi pregled podešavanja LightScripta iz perspektive održavanja, sa fokusom na to gde se tipično javljaju problemi i kako prepoznati i otkloniti greške. Najpre će se kratko proći kroz idealnu strukturu LightScripta, zatim obraditi otklanjanje grešaka i zaključiti sa FAQ-om.

Osnovna skeleton struktura zahteva <head>, <body> i <script>. Sve deklaracije merača i korisničkih kontrola idu u <head>. Sve deklaracije canvas-a idu u <body>. Sve ostalo treba postaviti u odeljak <script>.

<head>

<head> je jedan od najkritičnijih i najsloženijih delova LightScripta. Neispravna korisnička kontrola ili merač ovde može uzrokovati petlje pada ili deaktivirati sebe i sve merače deklarisane nakon njega.

Kada kreirate merače, obavezno osigurajte:

Savršenu sintaksu (da biste izbegli padove i neispravne merače)
Nema dupliranih imena merača (duplikati se prepisuju)
Nema merača koji prelaze granice ekrana (uzrokuje padove i greške)
Nema nedostajućih ili viška opcija u meračima (dovodi do padova)
Svi merači sadrže prilagođavanja rezolucije (osigurava konzistentno ponašanje)

Što se tiče rezolucija, najčešći odnosi stranica su:

16:9 (3840x2160, 2560x1440, 1920x1080, 1600x900, 1366x768, 1360x768, 1280x720)
16:10 (2560x1600, 1920x1200, 1680x1050, 1440x900, 1280x800)
21:9 (5120x2160, 3440x1440)

Podrazumevano se koristi rezolucija 2560x1440.

Svi LightScripts moraju podržavati odnose stranica 16:9, 16:10 i 21:9. Iako 4:3 ne čini značajan deo korisničke baze, treba ga uzeti u obzir za buduću kompatibilnost.

Evo primera strukture merača sa više podešavanja rezolucije:

Podrazumevana pozicija i veličina merača primenjuje se na sve ostale rezolucije unutar istog odnosa stranica. Na primer, ako su merači originalno podešeni za 1600x900, trebalo bi da ispravno rade na svim ostalim rezolucijama 16:9. Međutim, postoje izuzeci. Fortnite ima nekoliko različitih pozicija merača čak i unutar istog odnosa stranica, a neki odnosi stranica sami po sebi mogu biti zbunjujući. Na primer, 1366x768, globalno česta rezolucija, često se navodi kao 16:9, ali nije pravi 16:9 odnos — što nije neuobičajeno. Slično važi i za ultrawide odnose kao što je 21:9, koji retko odgovaraju njihovim nominalnim dimenzijama. U iskustvu kao programer integracija, još nije susrećena tačna 21:9 rezolucija, iako se tako nazivaju. Stoga svaka ultrawide rezolucija mora biti pojedinačno kreirana, testirana i konfigurisana.

Sva prilagođavanja moraju biti postavljena između otvarajućih <meta> i zatvarajućih </meta> tagova; u suprotnom neće funkcionisati. Ako je podrazumevani merač zasnovan na 16:9 i dosljedno radi na tim rezolucijama, nije potrebno dodavati prilagođavanja za druge 16:9 rezolucije. Međutim, moraju se dodati unosi za svaku rezoluciju u drugim odnosima stranica (kao što su 16:10 i 21:9), čak i ako je odnos konzistentan.

Konačno, svaki merač osim OCR merača zahteva HSL opseg za aktiviranje. Ovi opsezi mogu biti otežani sledećim faktorima:

Transparentni elementi korisničkog interfejsa
Gradijenti u oblastima boja
Efekti izobličavanja slike
Otvaranje igračkih menija
Prilagođavanja korisničkog interfejsa po rezoluciji
Kontroler nasuprot korišćenja tastature
Video snimci koji mogu uvoditi greške piksela vezane za kompresiju

Osnovna uputstva za HSL i normalizovane koordinate obrađena su u razvojnoj dokumentaciji i neće biti ponavljana ovde. Testiranje ovih merača se razmatra u odeljku “Identifikacija problema”, ali važno je naglasiti sledeće: Napor testiranja za savršenu verifikaciju svih merača izračunava se kao (broj merača) × (broj prilagođavanja rezolucije) × (broj načina igre) × (broj playable likova) × (dužina prosečne igre). To može lako postati satima provere po igri, posebno kada su načini vežbe ili drugi zaobilaznici nedostupni.

ČUVAJTE MERAČE EFIKASNIM — naš standard je perfekcija.

<body>

<body> tag je mesto gde se deklariše stvarni canvas element. Uvek bi trebalo da izgleda otprilike kao sledeći primer. Stvarni id canvas-a se može promeniti, ali osigurajte da se ispravno preuzima u skripti.

Uštedite vreme i kopirajte ovaj primer.

<script>

Četiri stvari se moraju desiti u ovom tagu za svaku integraciju:

Canvas se preuzima i koristi za kreiranje 2D konteksta.
Prva petlja ažuriranja postavlja vrednosti merača, a zatim se beskonačno ponovo poziva da ih održava.
Petlja ažuriranja čuva promenljive korisničkih kontrola ažuriranim.
Merači izvršavaju svoje callback funkcije kada su stabilni.

Opšti pristup

Osnovna skeleton struktura koda je već podešena. Sledeći korak je prolazak kroz petlju izvršavanja koja aktivira efekte od početka do kraja.

Korisnički interfejs video igre prikazuje informacije u obliku obojenih traka, dugmadi, tekstualnih polja itd. SignalRGB preuzima ove podatke više puta u sekundi, ali stvarna stopa preuzimanja jako zavisi od efikasnosti koda. Napomena: Jedna petlja ili nedeklarisana promenljiva može prekinuti celu skriptu i čak uzrokovati pad SignalRGBa. Što je gore, lako je pisati kod koji tehnički funkcioniše, ali je toliko neefikasan da preuzima informacije samo pri 1–2 FPS.
Svaki merač deklarisan u <head> mora biti što manji i efikasniji kako bi se smanjio overhead. Rano i često vršite izračunavanja; merač koji zauzima 25% ekrana nikada nije efikasan. Za OCR merače, hvatajte pojedinačna slova umesto celih reči. Za trake zdravlja i mane, pratite samo bitne segmente. ČUVAJTE MERAČE ŠTO MANJIM.
Merači preuzimaju informacije koje se ažuriraju sa svakom petljom.
Ranije je obrađena definicija klase Meter, koja čuva podatke merača i aktivira callback kada niz informacija postane stabilan. Na početku skripte deklarišite sve Meter instance u jednom bloku. Mogu biti organizovane ili poređane abecednim redom; samo ne treba da budu raspoređene kroz hiljade linija. U nekom trenutku biće potrebno podesiti vrednosti stabilnosti, a gubljenje vremena na pamćenje gde su postavljene je rasipanje vremena.
Unutar funkcije ažuriranja, ovi merači primaju vrednosti iz logike čitanja ekrana u svakoj petlji. Njihova interna logika procenjuje stabilnost i, kada je stabilna, aktivira asociranu callback funkciju.
Ove callback funkcije treba deklarisati u skripti, ali izvan funkcije ažuriranja. U njima se proverava stanje vrednosti Meter (value, decreased, increased, diff) i na osnovu toga određuje da li treba pokrenuti animaciju efekta. Strukturiranjem koda na ovaj način, umesto stavljanja svega direktno u petlju ažuriranja, omogućava se izgradnja skalabilnih integracija.

Primer iz prakse

Nakon što je opšta ideja poznata, brzo se prolazi kroz primer stvarne petlje.

Igra se igra League of Legends, koji označava dostupne veštine sa svetlim žutim isticanjem.
U svakoj petlji, specifični merač veštine uzima ovu boju kao vrednost “1” jer potpuno zadovoljava HSL opseg merača.
Ova “1” se prosleđuje Meter instanci koja je uparena sa meračem čitanja ekrana i ubacuje u niz informacija tog Metera.
Kada je svaka vrednost u tom nizu “1”, smatra se stabilnom i aktivira asociranu callback funkciju efekta. Ova callback funkcija bi se takođe aktivirala ako bi svaka vrednost bila “0” ili “.1”; Meteru je stalo samo do stabilnosti. Važna napomena je da se callback funkcija ne aktivira kontinuirano kada je Meter konstantno stabilan na istoj vrednosti — samo stabilnost sa NOVOM vrednošću aktivira callback.
Kada se callback funkcija izvrši, vrše se neke uslovne provere — u ovom slučaju samo treba proveriti da li je Meter.value “0”, što znači da je veština korišćena.
Pošto je vrednost merača “1”, ova provera ne prolazi i efekat veštine se ne reprodukuje.
Nekoliko sekundi kasnije veština se aktivira i žuto isticanje oko dugmeta nestaje.
Nova vrednost merača je 0, koja se prosleđuje svojoj Meter klasi.
Kada se postigne stabilnost, callback aktivira uslov i reprodukuje se efekat veštine. Latencija zavisi potpuno od dužine Meter niza, koja se postavlja pri deklaraciji. Više dužine znači više latencije i manje lažnih aktiviranja; stoga treba testirati dok se ne pronađe dobra ravnoteža.

Konvencije imenovanja

Merači čitanja ekrana treba da imaju jednostavna, jasna i opisna imena, uvek počinjući malim slovom. Nazvati merač trake zdravlja “healthBar” je odlično. Nazvati dva merača “healthBarRed” i “healthBarGreen” kada prate različite boje u istoj oblasti je takođe dobro. Ali nazvati mali merač koji se pojavljuje samo tokom ultimativne veštine heroja “hrO21_yes” stvara samo bol i patnju svakome ko mora da popravlja kod. Otkrivanje šta prati loše imenovan, sitan merač može doslovno oduzeti sat gledanja u pojedinačne piksele — zato treba izbegavati ovu grešku.

Meter klase instance treba da budu napisane velikim slovom i završavaju rečju Meter. Primeri kao što su “Q_Meter”, “TookDamageMeter” i “TowerDestroyedMeter” su svi u redu. Trebalo bi da budu jasno razlikujući od merača deklarisanih u odeljku <head>.

Funkcije efekata treba takođe da budu što jednostavnije i opisnije. Neke igre imaju stotine ovih funkcija; druge imaju manje od deset. Kada više heroja ima jedinstvene veštine, dodajte ime heroja kao prefiks, kao “SonaQ”, “ChamberE” ili “AshUlt”. Na primer, u League of Legends postoje funkcije kao što su “DragonEffect”, “TowerEffect” i “Q_Effects”, koje sadrže više uslova i koriste se od strane više merača. Ovakav način imenovanja stoga pomaže i u optimizaciji za skalabilnost.

Ne pravite greške u pisanju. Ako niste sigurni u pravopis, potražite ga. Imena moraju biti jasna i čitljiva, bez obzira ko radi na kodu ili koliko je vremena prošlo. Abecedno sortiranje imena pomaže pri brzom pretraživanju, posebno kada se ovaj odeljak često uređuje. Iako ovaj nivo organizacije nije neophodan za izvršavanje koda, pravi veliku razliku za programere koji vrše održavanje.