Panduan Kerangka

Bahagian ini menggariskan struktur asas integrasi LightScript, merangkumi keperluan teknikal utama, contoh dunia sebenar, konvensyen penamaan, dan petua kecekapan. Ia membimbing melalui gelung kemaskini, tingkah laku meter, logik pencetus kesan, dan menyerlahkan perangkap yang biasa. Sama ada Anda melakukan penyahpepijatan, membina dari awal, atau menyelenggara kod orang lain, panduan ini menekankan kejelasan, kestabilan, dan prestasi sebagai standard teras integrasi berkualiti tinggi.

Susun Atur Asas

Bahagian ini memberikan gambaran keseluruhan ringkas tentang penyediaan LightScript dari perspektif penyelenggaraan, dengan fokus pada di mana masalah biasanya berlaku dan cara mengenal pasti dan membetulkan pepijat. Kita akan mulakan dengan panduan ringkas tentang struktur LightScript yang ideal untuk membiasakan Anda dengan kod, kemudian merangkumi penyelesaian masalah, dan akhiri dengan Soalan Lazim.

Kerangka asas memerlukan <head>, <body>, dan <script>. Semua pengisytiharan meter dan kawalan pengguna masuk ke dalam <head>. Semua pengisytiharan kanvas tergolong dalam <body>. Semua yang lain harus diletakkan dalam bahagian <script>.

<head>

<head> adalah salah satu bahagian yang paling kritikal dan kompleks dalam mana-mana LightScript. Kawalan pengguna atau meter yang cacat di sini boleh menyebabkan gelung ranap atau melumpuhkan dirinya sendiri dan mana-mana meter yang diisytiharkan selepasnya.

Apabila mencipta meter, Anda perlu memastikan:

Sintaks yang sempurna (untuk mengelakkan ranap dan meter yang rosak)
Tiada nama meter pendua (pendua akan ditimpa)
Tiada meter yang meluas melepasi sempadan skrin (menyebabkan ranap dan ralat)
Tiada pilihan yang hilang atau tambahan dalam meter (membawa kepada ranap)
Semua meter termasuk pelarasan resolusi (memastikan tingkah laku yang konsisten)

Mengenai resolusi, nisbah aspek yang paling biasa adalah:

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

Secara lalai, kita menggunakan resolusi 2560x1440.

Semua LightScripts mesti menyokong nisbah aspek 16:9, 16:10, dan 21:9. Walaupun 4:3 tidak mewakili sebahagian besar pengguna kami, ia masih harus dipertimbangkan untuk keserasian masa hadapan.

Berikut adalah contoh struktur untuk meter dengan berbilang tetapan resolusi:

Lokasi dan saiz lalai meter Anda berlaku untuk setiap resolusi lain dalam nisbah aspek yang sama. Sebagai contoh, jika Anda pada asalnya menyesuaikan meter Anda untuk berfungsi dengan 1600x900, meter itu sepatutnya berfungsi dengan betul merentas semua resolusi 16:9 lain. Namun, terdapat pengecualian. Fortnite mempunyai berbilang kedudukan meteran yang berbeza walaupun dalam nisbah aspek yang sama, dan beberapa nisbah aspek itu sendiri boleh mengelirukan. Sebagai contoh, 1366x768, resolusi yang biasa di seluruh dunia, sering disenaraikan sebagai 16:9 tetapi sebenarnya bukan nisbah 16:9 yang sebenar, yang tidak luar biasa. Begitu juga, nisbah ultrawide seperti 21:9 jarang sepadan dengan dimensi nominalnya. Dalam pengalaman saya sebagai pembangun integrasi, saya tidak pernah menemui resolusi 21:9 yang tepat walaupun ia dilabelkan demikian. Oleh itu, setiap resolusi ultrawide mesti dicipta, diuji, dan dikonfigurasi secara individu.

Semua pelarasan mesti diletakkan antara tag pembuka <meta> dan penutup </meta>; jika tidak, ia tidak akan berfungsi. Jika meter lalai Anda adalah berdasarkan 16:9 dan berkelakuan konsisten merentas resolusi tersebut, Anda tidak perlu menambah pelarasan untuk resolusi 16:9 lain. Namun, Anda mesti menambah entri untuk setiap resolusi dalam nisbah aspek lain (seperti 16:10 dan 21:9), walaupun nisbahnya konsisten.

Akhirnya, setiap meter kecuali meter OCR kami memerlukan julat HSL untuk dicetuskan. Julat-julat ini boleh dikomplikasikan oleh faktor-faktor seperti:

Elemen UI yang telus
Kecerunan dalam kawasan warna
Kesan pembelokan skrin
Pembukaan menu dalam permainan
Pelarasan UI setiap resolusi
Penggunaan pengawal berbanding papan kekunci
Rakaman video, yang boleh memperkenalkan ralat piksel berkaitan mampatan

Arahan asas tentang HSL dan koordinat yang dinormalkan diliputi dalam dokumen pembangun kami dan tidak akan diulang di sini. Pengujian meter ini akan dibincangkan dalam bahagian “Mengenal Pasti Isu”, tetapi penting untuk menekankan perkara ini: jumlah pengujian yang diperlukan untuk mengesahkan semua meter dengan sempurna dikira sebagai (bilangan meter) × (bilangan pelarasan resolusi) × (bilangan mod permainan) × (bilangan aksara yang boleh dimainkan) × (tempoh permainan purata). Ini boleh dengan mudah menambah hingga berjam-jam pengesahan setiap permainan, terutamanya jika mod latihan atau penyelesaian lain tidak tersedia.

PASTIKAN METER ANDA CEKAP, standard kami adalah kesempurnaan.

<body>

Tag <body> adalah tempat elemen kanvas sebenar diisytiharkan. Ia harus sentiasa kelihatan lebih kurang seperti contoh berikut. Id kanvas sebenar boleh ditukar jika Anda mahu, tetapi pastikan Anda mengambilnya dengan betul dalam skrip.

Jimatkan masa Anda dan salin-tampal ini.

<script>

Empat perkara mesti berlaku di dalam tag ini dalam setiap integrasi

Kanvas diambil dan digunakan untuk mencipta konteks 2D kami.
Gelung kemaskini awal menetapkan nilai meter, kemudian memanggil semula dirinya sendiri tanpa had untuk mengekalkannya.
Gelung kemaskini memastikan pemboleh ubah kawalan pengguna dikemas kini.
Meter melaksanakan fungsi panggilan balik mereka apabila stabil.

Prosedur Umum

Kita telah menyediakan kerangka kod asas. Langkah seterusnya adalah untuk melalui gelung pelaksanaan yang mencetuskan kesan dari awal hingga akhir.

UI permainan video memaparkan maklumat dalam bentuk bar berwarna, butang, kotak teks, dll. SignalRGB menangkap data ini beberapa kali sesaat, tetapi kadar tangkapan sebenar sangat bergantung pada kecekapan kod Anda. Untuk menjadi jelas, satu gelung atau pemboleh ubah yang tidak diisytiharkan boleh merosakkan keseluruhan skrip Anda, dan bahkan meruntuhkan SignalRGB. Lebih teruk, mudah untuk menulis kod yang secara teknikal berfungsi, tetapi sangat tidak cekap sehingga ia menangkap maklumat hanya pada 1-2 FPS.
Setiap meter yang diisytiharkan dalam <head> mesti sekecil dan seefisien mungkin untuk mengurangkan overhead. Lakukan pengiraan Anda awal dan kerap; meter yang mengambil 25% skrin tidak pernah cekap. Dengan meter OCR, tangkap huruf individu dan bukannya keseluruhan perkataan. Untuk bar kesihatan dan mana, pantau hanya segmen yang penting. PASTIKAN METER ANDA SEKECIL YANG MUNGKIN.
Meter menangkap maklumat yang menyegar dengan setiap gelung.
Sebelumnya, kita membincangkan definisi kelas Meter, yang menyimpan data meter dan mencetuskan panggilan balik apabila susunan maklumat menjadi stabil. Di bahagian atas skrip Anda, isytiharkan semua Meter dalam satu blok. Anda boleh mengatur atau mengabjad mereka; hanya jangan tanam mereka merentas beribu-ribu baris. Anda akhirnya perlu menala nilai kestabilan, dan ia membuang masa untuk cuba mengingati di mana Anda meletakkannya.
Di dalam fungsi kemaskini, meter ini akan menerima nilai daripada logik pembacaan skrin setiap gelung. Logik dalaman mereka menilai kestabilan dan, apabila stabil, mencetuskan fungsi panggilan balik yang berkaitan.
Fungsi panggilan balik ini harus diisytiharkan dalam skrip Anda tetapi di luar fungsi kemaskini. Di dalamnya, semak keadaan nilai Meter Anda (value, decreased, increased, diff) dan gunakan ini untuk menentukan sama ada kesan animasi harus dimainkan. Menstrukturkan kod Anda dengan cara ini, daripada meletakkan segala-galanya terus dalam gelung kemaskini, membolehkan kita membina integrasi yang boleh diskalakan.

Contoh Dunia Sebenar

Kini setelah Anda memahami idea umum, saya akan dengan cepat melalui contoh gelung dunia sebenar.

Saya sedang bermain permainan League of Legends, yang mengelilingi kemahiran yang tersedia dengan sorotan kuning terang.
Setiap gelung, meter kemahiran khusus mengambil warna ini sebagai nilai “1” kerana ia sepenuhnya lulus julat HSL meter.
“1” ini dihantar ke contoh Meter yang dilampirkan pada meter pembacaan skrin dan dimasukkan ke dalam susunan maklumat Meter tersebut.
Jika setiap nilai dalam susunan itu adalah “1”, ia dianggap stabil, dan akan mengaktifkan fungsi panggilan balik kesan yang dilampirkan. Fungsi panggilan balik ini juga akan diaktifkan jika setiap nilai adalah “0”, atau “.1” misalnya; semua yang Meter peduli adalah kestabilan. Satu nota penting di sini ialah fungsi panggilan balik tidak akan terus diaktifkan jika Meter sentiasa stabil pada nilai yang sama – hanya kestabilan dengan nilai BARU yang akan mengaktifkan panggilan balik.
Setelah fungsi panggilan balik dilaksanakan, kita sampai kepada beberapa pemeriksaan bersyarat – dalam kes ini, yang perlu kita lakukan adalah memeriksa apakah Meter.value adalah “0”, menunjukkan kemahiran telah digunakan.
Memandangkan nilai Meter adalah “1”, kita gagal pemeriksaan ini dan tidak akan memainkan kesan kemahiran.
Beberapa saat kemudian, saya mengaktifkan kemahiran dan sorotan kuning di sekeliling butang hilang.
Nilai meter baru adalah 0, yang dihantar ke kelas Meter-nya.
Setelah kestabilan dicapai, panggilan balik diaktifkan dan syarat bersyarat kami dilalui, memainkan kesan kemahiran. Kelewatan bergantung sepenuhnya pada panjang susunan Meter, yang Anda tetapkan pada pengisytiharannya. Panjang yang lebih tinggi bermakna lebih banyak kelewatan dan lebih sedikit pencetus palsu, jadi pastikan untuk menguji sehingga Anda menemui keseimbangan yang baik.

Konvensyen Penamaan

Meter pembacaan skrin harus mempunyai nama yang mudah, jelas, dan deskriptif, sentiasa bermula dengan huruf kecil. Menamakan meter bar kesihatan “healthBar” adalah cemerlang. Menamakan dua meter “healthBarRed” dan “healthBarGreen” apabila mereka menjejaki warna yang berbeza di kawasan yang sama juga bagus. Tetapi menamakan meter kecil yang hanya muncul semasa kesan ultimate satu wira sebagai “hrO21_yes” hanya akan membawa kesakitan dan penderitaan kepada sesiapa sahaja yang cuba membetulkan kod Anda. Menentukan apa yang dijejaki oleh meter yang dinamai dengan buruk dan kecil boleh mengambil masa satu jam menatap piksel individu jika Anda tidak bernasib baik, jadi jangan lakukan ini.

Contoh kelas Meter harus dikapitalkan dan berakhir dengan perkataan Meter. Contoh seperti “Q_Meter”, “TookDamageMeter”, dan “TowerDestroyedMeter” semua baik. Ini harus dapat dibezakan dengan jelas daripada meter yang diisytiharkan dalam bahagian <head>.

Fungsi kesan juga harus dinamai semudah dan sedeskriptif mungkin. Beberapa permainan mempunyai ratusan fungsi ini; yang lain mungkin mempunyai kurang daripada sepuluh. Jika berbilang wira mempunyai kemahiran unik, sertakan nama wira sebagai awalan, seperti “SonaQ”, “ChamberE”, atau “AshUlt”. Dalam League of Legends, sebagai contoh, terdapat fungsi seperti “DragonEffect”, “TowerEffect”, dan “Q_Effects”, yang mengandungi berbilang syarat bersyarat dan digunakan oleh beberapa meter. Jadi, penamaan jenis ini juga membantu mengoptimumkan untuk skala.

Jangan salah eja perkataan. Jika Anda tidak pasti cara mengeja sesuatu, carinya. Nama mesti jelas dan boleh dibaca, tanpa mengira siapa yang mengerjakan kod atau berapa banyak masa yang telah berlalu. Mengatur nama secara abjad membantu dengan carian cepat, terutamanya jika Anda akan sering mengedit bahagian tersebut. Walaupun tahap organisasi ini tidak diperlukan untuk kod berjalan, ia membuat perbezaan besar untuk pembangun penyelenggaraan kami.