İskelet Kılavuzu

Bu bölüm, temel teknik gereksinimleri, gerçek dünya örneklerini, adlandırma kurallarını ve verimlilik ipuçlarını kapsayan bir LightScript entegrasyonunun temel yapısını özetlemektedir. Güncelleme döngüsü, metre davranışı, efekt tetikleme mantığı üzerinden geçer ve yaygın tuzakları vurgular. İster hata ayıklıyor, ister sıfırdan oluşturuyor, ister başkasının kodunu bakıyor olun, bu kılavuz netlik, kararlılık ve performansı yüksek kaliteli entegrasyonların temel standartları olarak vurgular.

Temel Düzen

Bu bölüm, sorunların genellikle nerede ortaya çıktığına ve hataların nasıl tespit edilip düzeltileceğine odaklanarak bakım perspektifinden bir LightScript kurulumuna hızlı bir genel bakış sunar. Kodu tanımanız için ideal bir LightScript yapısının kısa bir incelemesiyle başlayacağız, ardından sorun gidermeyi ele alacağız ve bir SSS ile bitireceğiz.

Temel iskelet bir <head>, <body> ve <script> gerektirir. Tüm metre ve kullanıcı kontrolü bildirimleri <head> içine gider. Tüm canvas bildirimleri <body>‘e aittir. Diğer her şey <script> bölümüne yerleştirilmelidir.

<head>

<head> herhangi bir LightScript’in en kritik ve karmaşık bölümlerinden biridir. Buradaki hatalı bir kullanıcı kontrolü veya metre, çökme döngülerine neden olabilir veya kendisini ve sonrasında bildirilen tüm metreleri devre dışı bırakabilir.

Metre oluştururken şunları sağlamanız gerekir:

Mükemmel sözdizimi (çökmelerden ve bozuk metrelerden kaçınmak için)
Yinelenen metre adı yok (yinelemeler üzerine yazılır)
Ekran sınırlarını aşan metre yok (çökmelere ve hatalara neden olur)
Metrelerde eksik veya fazla seçenek yok (çökmelere yol açar)
Tüm metreler çözünürlük ayarlamaları içermeli (tutarlı davranışı sağlar)

Çözünürlükler açısından en yaygın en-boy oranları şunlardır:

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

Varsayılan olarak 2560x1440 çözünürlüğünü kullanırız.

Tüm LightScript’ler 16:9, 16:10 ve 21:9 en-boy oranlarını desteklemelidir. 4:3 kullanıcı tabanımızın önemli bir bölümünü temsil etmese de gelecekte uyumluluk için göz önünde bulundurulmalıdır.

Birden fazla çözünürlük ayarına sahip bir metre yapısı örneği:

Metrelerinizin varsayılan konumu ve boyutu, aynı en-boy oranındaki diğer tüm çözünürlükler için geçerlidir. Örneğin, metrelerinizi başlangıçta 1600x900 ile çalışacak şekilde ayarlarsanız, bu metre diğer tüm 16:9 çözünürlüklerinde düzgün çalışmalıdır. Ancak istisnalar vardır. Fortnite aynı en-boy oranı içinde bile birden fazla farklı metreleme konumuna sahiptir ve bazı en-boy oranlarının kendisi de yanıltıcı olabilir. Örneğin dünya genelinde yaygın bir çözünürlük olan 1366x768, genellikle 16:9 olarak listelenir ancak gerçekte tam bir 16:9 oranı değildir; bu alışılmadık bir durum değildir. Benzer şekilde 21:9 gibi geniş ekran oranları nadiren nominal boyutlarıyla eşleşir. Entegrasyon geliştiricisi olarak deneyimlerimde, bu şekilde etiketlenmelerine rağmen hiçbir zaman tam bir 21:9 çözünürlüğüyle karşılaşmadım. Bu nedenle her geniş ekran çözünürlüğü ayrı ayrı oluşturulmalı, test edilmeli ve yapılandırılmalıdır.

Tüm ayarlamalar açılış <meta> ve kapanış </meta> etiketleri arasına yerleştirilmelidir; aksi takdirde çalışmazlar. Varsayılan metreniz 16:9 temelindeyse ve bu çözünürlüklerde tutarlı davranıyorsa, diğer 16:9 çözünürlükleri için ayarlama eklemeniz gerekmez. Ancak oran tutarlı olsa bile diğer en-boy oranlarındaki (16:10 ve 21:9 gibi) her çözünürlük için giriş eklemeniz gerekir.

Son olarak, OCR metrelerimiz dışındaki her metre tetiklemek için bir HSL aralığı gerektirir. Bu aralıklar şu gibi faktörler tarafından karmaşık hale getirilebilir:

Şeffaf arayüz öğeleri
Renk alanlarındaki degradeler
Ekran bozulma efektleri
Oyun içi menü açılışları
Çözünürlük başına arayüz ayarlamaları
Kontrolcü ve klavye kullanımı
Sıkıştırmayla ilgili piksel hatalarına yol açabilen video kaydı

HSL ve normalleştirilmiş koordinatlar hakkında temel talimatlar geliştirici belgelerimizde ele alınmaktadır ve burada tekrarlanmayacaktır. Bu metrelerin test edilmesi “Sorunları Belirleme” bölümünde ele alınacaktır, ancak şunu vurgulamak önemlidir: tüm metreleri mükemmel şekilde doğrulamak için gereken test miktarı (metre sayısı) × (çözünürlük ayarlamaları sayısı) × (oyun modu sayısı) × (oynanabilir karakter sayısı) × (ortalama oyun uzunluğu) olarak hesaplanır. Bu, özellikle pratik modlar veya diğer geçici çözümler mevcut değilse oyun başına kolayca saatler süren doğrulamaya ulaşabilir.

METRELERİNİZİ VERİMLİ TUTUN, standardımız mükemmelliktir.

<body>

<body> etiketi, gerçek canvas öğesinin bildirildiği yerdir. Her zaman aşağıdaki örneğe az çok benzemelidir. Gerçek canvas id’si isterseniz değiştirilebilir, ancak betikte doğru şekilde getirdiğinizden emin olun.

Kendinize zaman kazandırın ve kopyalayıp yapıştırın.

<script>

Her entegrasyonda bu etiketin içinde dört şey gerçekleşmelidir:

Canvas getirilir ve 2D bağlamımızı oluşturmak için kullanılır.
İlk güncelleme döngüsü metre değerlerini ayarlar, ardından onları korumak için süresiz olarak kendini yeniden çağırır.
Güncelleme döngüsü kullanıcı kontrolü değişkenlerini güncel tutar.
Metreler kararlı olduklarında geri çağırma fonksiyonlarını çalıştırır.

Genel Prosedür

Temel kod iskeletini zaten oluşturduk. Bir sonraki adım, baştan sona efektleri tetikleyen yürütme döngüsü üzerinden geçmektir.

Video oyunu arayüzü, renkli çubuklar, düğmeler, metin kutuları vb. şeklinde bilgi görüntüler. SignalRGB bu veriyi saniyede birkaç kez yakalar, ancak gerçek yakalama hızı büyük ölçüde kodunuzun verimliliğine bağlıdır. Açıkça söylemek gerekirse, tek bir döngü veya bildirilmemiş değişken tüm betiğinizi bozabilir ve hatta SignalRGB’yi çökertebilir. Daha da kötüsü, teknik olarak çalışan ancak o kadar verimsiz olan kod yazmak kolaydır ki yalnızca 1-2 FPS’de bilgi yakalar.
<head>‘de bildirilen her metre, ek yükü azaltmak için mümkün olduğunca küçük ve verimli olmalıdır. Hesaplamalarınızı erken ve sık yapın; ekranın %25’ini kaplayan bir metre hiçbir zaman verimli değildir. OCR metrelerinde, tüm kelimeler yerine tek tek harfleri yakalayın. Sağlık ve mana çubukları için yalnızca temel segmentleri izleyin. METRELERİNİZİ OLABILDIĞINCE KÜÇÜK TUTUN.
Metreler her döngüyle yenilenen bilgileri yakalar.
Daha önce Metre sınıfı tanımını ele aldık; bu sınıf metre verilerini saklar ve bilgi dizisi kararlı hale geldiğinde bir geri çağırma tetikler. Betiğinizin üst kısmında tüm Metreleri bir blokta bildirin. Onları organize edebilir veya alfabetik sıraya koyabilirsiniz; sadece binlerce satıra gömmekten kaçının. Sonunda kararlılık değerlerini ayarlamanız gerekecektir ve onları nereye koyduğunuzu hatırlamaya çalışmak zaman kaybıdır.
Güncelleme fonksiyonunun içinde, bu metreler her döngüde ekran okuma mantığından değerler alacaktır. Dahili mantıkları kararlılığı değerlendirir ve kararlı olduğunda ilişkili geri çağırma fonksiyonunu tetikler.
Bu geri çağırma fonksiyonları, güncelleme fonksiyonunun dışında betiğinizde bildirilmelidir. İçlerinde, Metre değerlerinin durumunu (value, decreased, increased, diff) kontrol edin ve bunları bir efekt animasyonu oynatıp oynamayacağınızı belirlemek için kullanın. Kodunuzu bu şekilde yapılandırmak, her şeyi doğrudan güncelleme döngüsünün içine koymak yerine ölçeklenebilir entegrasyonlar oluşturmamıza olanak tanır.

Gerçek Dünya Örneği

Genel fikri anladığınıza göre gerçek bir dünya örnek döngüsünü hızlıca ele alacağım.

League of Legends oynuyorum; bu oyun mevcut becerileri parlak sarı bir vurguyla çevreliyor.
Her döngüde, belirli beceri metresi bu rengi “1” değeri olarak algılar çünkü metrenin HSL aralığını tamamen geçer.
Bu “1”, ekran okuma metresine bağlı Metre örneğine iletilir ve o Metre’nin bilgi dizisine eklenir.
Dizideki her değer “1” ise kararlı olarak kabul edilir ve ekli efekt geri çağırma fonksiyonunu etkinleştirir. Bu geri çağırma fonksiyonu, her değer “0” veya örneğin “.1” olsaydı da etkinleştirilirdi; Metre’nin önemsediği tek şey kararlılıktır. Burada dikkat edilmesi gereken önemli bir nokta, geri çağırma fonksiyonunun Metre aynı değerde sürekli kararlıysa sürekli etkinleştirilmeyeceğidir — yalnızca YENİ bir değerle kararlılık geri çağırmayı etkinleştirecektir.
Geri çağırma fonksiyonu yürütüldükten sonra bazı koşullu kontrollere geliyoruz — bu durumda tek yapmamız gereken Metre.value’nun “0” olup olmadığını kontrol etmek; bu bir becerinin kullanıldığını gösterir.
Metre değeri “1” olduğundan bu kontrolü geçemeyiz ve beceri efektini oynatmayacağız.
Birkaç saniye sonra beceriyi etkinleştiriyorum ve düğmenin etrafındaki sarı vurgu kayboluyor.
Yeni metre değeri 0’dır ve Metre sınıfına iletilir.
Kararlılığa ulaşıldığında geri çağırma etkinleşir ve koşulumuz geçilerek beceri efekti oynatılır. Gecikme tamamen bildirimdeki Metre dizisinin uzunluğuna bağlıdır. Daha fazla uzunluk, daha fazla gecikme ve daha az yanlış tetikleme anlamına gelir; bu nedenle iyi bir denge bulana kadar test ettiğinizden emin olun.

Adlandırma Kuralları

Ekran okuma metrelerinin basit, açık ve açıklayıcı adları olmalı ve her zaman küçük harfle başlamalıdır. Sağlık çubuğu metresini “healthBar” olarak adlandırmak mükemmeldir. Aynı alandaki farklı renkleri izlerken iki metreyi “healthBarRed” ve “healthBarGreen” olarak adlandırmak da çok iyidir. Ancak yalnızca bir kahramanın nihai efekti sırasında görünen küçük bir metreyi “hrO21_yes” gibi bir şey olarak adlandırmak, kodunuzu düzeltmeye çalışan herkesin başını ağrıtacaktır. Kötü adlandırılmış, küçük bir metrenin neyi izlediğini anlamak, şanssızsanız bireysel piksellere bakarak gerçekten bir saatinizi alabilir; bu nedenle bunu yapmayın.

Metre sınıfı örnekleri büyük harfle başlamalı ve Metre kelimesiyle bitmelidir. “Q_Meter”, “TookDamageMeter” ve “TowerDestroyedMeter” gibi örnekler tamamen uygundur. Bunlar, <head> bölümünde bildirilen metrelerden açıkça ayırt edilebilir olmalıdır.

Efekt fonksiyonları da mümkün olduğunca basit ve açıklayıcı şekilde adlandırılmalıdır. Bazı oyunlarda bu fonksiyonların yüzlercesi bulunur; diğerlerinde ise on’dan azı olabilir. Birden fazla kahraman benzersiz becerilere sahipse, kahramanın adını “SonaQ”, “ChamberE” veya “AshUlt” gibi bir önek olarak ekleyin. Örneğin League of Legends’da “DragonEffect”, “TowerEffect” ve “Q_Effects” gibi birden fazla koşul içeren ve birçok metre tarafından kullanılan fonksiyonlar vardır. Dolayısıyla bu tür adlandırma ölçek için optimize etmeye de yardımcı olur.

Kelimeleri yanlış yazmayın. Bir şeyin nasıl yazıldığından emin değilseniz bakın. İsimler, kod üzerinde kimin çalıştığından veya ne kadar zaman geçtiğinden bağımsız olarak açık ve okunabilir olmalıdır. Adları alfabetik olarak düzenlemek, özellikle o bölümü sık sık düzenliyorsanız hızlı arama için yardımcı olur. Bu düzey organizasyon kodun çalışması için gerekli olmasa da bakım geliştiricilerimiz için büyük fark yaratır.