Hướng dẫn Skeleton

Phần này mô tả cấu trúc cơ bản của tích hợp LightScript và bao gồm các yêu cầu kỹ thuật quan trọng, ví dụ thực tế, quy ước đặt tên và mẹo hiệu quả. Nó hướng dẫn qua vòng lặp cập nhật, hành vi meter, logic kích hoạt hiệu ứng và nêu bật các lỗi phổ biến. Dù bạn đang gỡ lỗi, xây dựng từ đầu hay bảo trì code của người khác — hướng dẫn này nhấn mạnh sự rõ ràng, ổn định và hiệu suất như các tiêu chuẩn cốt lõi của các tích hợp chất lượng cao.

Cấu trúc cơ bản

Phần này cung cấp tổng quan nhanh về thiết lập LightScript từ góc độ bảo trì, tập trung vào nơi các vấn đề thường xảy ra và cách nhận biết và khắc phục lỗi. Đầu tiên sẽ đi qua cấu trúc LightScript lý tưởng, sau đó đề cập đến việc gỡ lỗi và kết thúc bằng FAQ.

Cấu trúc skeleton cơ bản yêu cầu <head>, <body> và <script>. Tất cả các khai báo meter và điều khiển người dùng đi vào <head>. Tất cả các khai báo canvas đi vào <body>. Mọi thứ khác nên được đặt trong phần <script>.

<head>

<head> là một trong những phần quan trọng và phức tạp nhất của LightScript. Điều khiển người dùng hoặc meter không đúng ở đây có thể gây ra vòng lặp sự cố hoặc vô hiệu hóa chính nó và tất cả các meter được khai báo sau đó.

Khi tạo meter, hãy đảm bảo:

Cú pháp hoàn hảo (để tránh sự cố và meter không đúng)
Không có tên meter trùng lặp (các bản sao bị ghi đè)
Không có meter vượt quá ranh giới màn hình (gây sự cố và lỗi)
Không thiếu hoặc thừa tùy chọn trong meter (dẫn đến sự cố)
Tất cả meter chứa các điều chỉnh độ phân giải (đảm bảo hành vi nhất quán)

Về độ phân giải, các tỷ lệ khung hình phổ biến nhất là:

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

Mặc định sử dụng độ phân giải 2560x1440.

Tất cả LightScripts phải hỗ trợ tỷ lệ khung hình 16:9, 16:10 và 21:9. Mặc dù 4:3 không chiếm phần lớn cơ sở người dùng, nó nên được xem xét để tương thích trong tương lai.

Đây là ví dụ về cấu trúc meter với nhiều cài đặt độ phân giải:

Vị trí và kích thước meter mặc định được áp dụng cho tất cả các độ phân giải khác trong cùng tỷ lệ khung hình. Ví dụ: nếu các meter ban đầu được cài đặt cho 1600x900, chúng sẽ hoạt động đúng trên tất cả các độ phân giải 16:9 khác. Tuy nhiên, có các ngoại lệ. Fortnite có một số vị trí meter khác nhau ngay cả trong cùng tỷ lệ khung hình, và một số tỷ lệ khung hình có thể gây nhầm lẫn. Ví dụ: 1366x768, một độ phân giải phổ biến toàn cầu, thường được gọi là 16:9 nhưng không phải tỷ lệ 16:9 thực sự — điều này không phải là hiếm gặp. Điều tương tự áp dụng cho các tỷ lệ siêu rộng như 21:9, hiếm khi khớp với kích thước danh nghĩa của chúng. Do đó mỗi độ phân giải siêu rộng phải được tạo, kiểm tra và cấu hình riêng lẻ.

Tất cả các điều chỉnh phải được đặt giữa các thẻ <meta> mở và </meta> đóng; nếu không chúng sẽ không hoạt động. Nếu meter mặc định dựa trên 16:9 và hoạt động nhất quán trên các độ phân giải đó, không cần thêm điều chỉnh cho các độ phân giải 16:9 khác. Tuy nhiên, phải thêm các mục cho mỗi độ phân giải trong các tỷ lệ khung hình khác (như 16:10 và 21:9), ngay cả khi tỷ lệ nhất quán.

Cuối cùng, mọi meter trừ meter OCR yêu cầu phạm vi HSL để kích hoạt. Các phạm vi này có thể bị ảnh hưởng bởi các yếu tố sau:

Các phần tử giao diện người dùng trong suốt
Gradient trong các vùng màu
Hiệu ứng méo hình ảnh
Mở menu trong trò chơi
Điều chỉnh giao diện người dùng theo độ phân giải
Dùng tay cầm so với dùng bàn phím
Các đoạn video có thể gây ra các lỗi pixel liên quan đến nén

Hướng dẫn cơ bản về HSL và tọa độ chuẩn hóa đã được đề cập trong tài liệu phát triển và sẽ không được lặp lại ở đây. Việc kiểm tra các meter này được xem xét trong phần “Xác định vấn đề”, nhưng điều quan trọng cần nhấn mạnh là: Nỗ lực kiểm tra để xác minh hoàn hảo tất cả các meter được tính bằng (số meter) × (số điều chỉnh độ phân giải) × (số chế độ trò chơi) × (số nhân vật có thể chơi) × (thời lượng trò chơi trung bình). Điều này dễ dàng trở thành nhiều giờ kiểm tra mỗi trò chơi, đặc biệt khi các chế độ thực hành hoặc các cách giải quyết khác không có sẵn.

GIỮ CÁC METER HIỆU QUẢ — tiêu chuẩn của chúng ta là hoàn hảo.

<body>

Thẻ <body> là nơi khai báo phần tử canvas thực sự. Nó luôn nên trông giống như ví dụ sau. id thực tế của canvas có thể thay đổi, nhưng hãy đảm bảo nó được lấy đúng trong script.

Tiết kiệm thời gian và sao chép ví dụ này.

<script>

Bốn thứ phải xảy ra trong thẻ này cho mỗi tích hợp:

Canvas được lấy và sử dụng để tạo bối cảnh 2D.
Vòng lặp cập nhật đầu tiên đặt các giá trị meter, sau đó tự gọi lại vô hạn để duy trì chúng.
Vòng lặp cập nhật giữ các biến điều khiển người dùng được cập nhật.
Meter thực thi các hàm callback khi ổn định.

Cách tiếp cận chung

Cấu trúc skeleton code cơ bản đã được thiết lập. Bước tiếp theo là đi qua vòng lặp thực thi kích hoạt các hiệu ứng từ đầu đến cuối.

Giao diện người dùng của trò chơi điện tử hiển thị thông tin dưới dạng thanh có màu, nút, hộp văn bản, v.v. SignalRGB lấy dữ liệu này nhiều lần mỗi giây, nhưng tốc độ lấy thực tế phụ thuộc nhiều vào hiệu quả code. Lưu ý: Một vòng lặp hoặc biến chưa được khai báo có thể phá vỡ toàn bộ script và thậm chí gây sự cố SignalRGB. Tệ hơn, dễ dàng viết code hoạt động về mặt kỹ thuật nhưng kém hiệu quả đến mức chỉ lấy thông tin ở 1–2 FPS.
Mỗi meter được khai báo trong <head> phải càng nhỏ và hiệu quả càng tốt để giảm overhead. Thực hiện tính toán sớm và thường xuyên; meter chiếm 25% màn hình không bao giờ hiệu quả. Đối với meter OCR, nắm bắt từng chữ cái riêng lẻ thay vì toàn bộ từ. Đối với thanh sinh mạng và mana, chỉ theo dõi các phân đoạn quan trọng. GIỮ CÁC METER CÀNG NHỎ CÀNG TỐT.
Các meter lấy thông tin được cập nhật với mỗi vòng lặp.
Định nghĩa lớp Meter đã được đề cập trước đó, lưu trữ dữ liệu meter và kích hoạt callback khi một chuỗi thông tin trở nên ổn định. Ở đầu script, khai báo tất cả các thể hiện Meter trong một khối. Chúng có thể được tổ chức hoặc sắp xếp theo thứ tự bảng chữ cái; chỉ cần không phân tán chúng qua hàng nghìn dòng. Tại một thời điểm nào đó, giá trị ổn định sẽ cần được điều chỉnh, và lãng phí thời gian để nhớ chúng được đặt ở đâu là lãng phí thời gian.
Trong hàm cập nhật, các meter này nhận giá trị từ logic đọc màn hình trong mỗi vòng lặp. Logic nội bộ của chúng đánh giá sự ổn định và, khi ổn định, kích hoạt hàm callback liên quan.
Các hàm callback này nên được khai báo trong script, nhưng bên ngoài hàm cập nhật. Trong chúng, trạng thái của giá trị Meter (value, decreased, increased, diff) được kiểm tra và từ đó xác định liệu có nên chạy animation hiệu ứng không. Bằng cách cấu trúc code theo cách này, thay vì đặt mọi thứ trực tiếp vào vòng lặp cập nhật, cho phép xây dựng các tích hợp có thể mở rộng.

Ví dụ thực tế

Sau khi biết ý tưởng chung, hãy xem nhanh một ví dụ vòng lặp thực tế.

Trò chơi đang chơi là League of Legends, đánh dấu các kỹ năng có sẵn bằng màu vàng sáng.
Trong mỗi vòng lặp, meter kỹ năng cụ thể lấy màu này như giá trị “1” vì nó hoàn toàn thỏa mãn phạm vi HSL của meter.
“1” này được chuyển đến thể hiện Meter được ghép với meter đọc màn hình và đưa vào mảng thông tin của Meter đó.
Khi mọi giá trị trong mảng đó là “1”, nó được coi là ổn định và kích hoạt hàm callback hiệu ứng liên quan. Hàm callback này cũng sẽ kích hoạt nếu mọi giá trị là “0” hoặc “.1”; Meter chỉ quan tâm đến sự ổn định. Lưu ý quan trọng là hàm callback không kích hoạt liên tục khi Meter liên tục ổn định ở cùng một giá trị — chỉ ổn định với giá trị MỚI mới kích hoạt callback.
Khi hàm callback thực thi, một số kiểm tra điều kiện được thực hiện — trong trường hợp này chỉ cần kiểm tra xem Meter.value có phải là “0” không, có nghĩa là kỹ năng đã được sử dụng.
Vì giá trị meter là “1”, kiểm tra này không vượt qua và hiệu ứng kỹ năng không được phát.
Vài giây sau kỹ năng được kích hoạt và màu vàng nổi bật xung quanh nút biến mất.
Giá trị meter mới là 0, được chuyển đến lớp Meter của nó.
Khi đạt được sự ổn định, callback kích hoạt điều kiện và hiệu ứng kỹ năng được phát. Độ trễ hoàn toàn phụ thuộc vào độ dài mảng Meter, được đặt khi khai báo. Độ dài lớn hơn có nghĩa là độ trễ lớn hơn và ít kích hoạt sai hơn; do đó hãy kiểm tra cho đến khi tìm được sự cân bằng tốt.

Quy ước đặt tên

Meter đọc màn hình nên có tên đơn giản, rõ ràng và mô tả, luôn bắt đầu bằng chữ thường. Đặt tên meter thanh sinh mạng là “healthBar” là tuyệt vời. Đặt tên hai meter là “healthBarRed” và “healthBarGreen” khi chúng theo dõi các màu khác nhau trong cùng một vùng cũng tốt. Nhưng đặt tên một meter nhỏ chỉ xuất hiện trong kỹ năng tối thượng của anh hùng là “hrO21_yes” chỉ tạo ra đau khổ cho bất kỳ ai phải sửa code. Tìm hiểu một meter được đặt tên xấu, nhỏ có thể thực sự tốn một giờ nhìn vào từng pixel riêng lẻ — vì vậy hãy tránh sai lầm này.

Thể hiện lớp Meter nên được viết hoa và kết thúc bằng từ Meter. Các ví dụ như “Q_Meter”, “TookDamageMeter” và “TowerDestroyedMeter” đều ổn. Chúng nên phân biệt rõ ràng với các meter được khai báo trong phần <head>.

Hàm hiệu ứng cũng nên càng đơn giản và mô tả càng tốt. Một số trò chơi có hàng trăm hàm này; những trò khác có ít hơn mười. Khi nhiều anh hùng có kỹ năng độc đáo, thêm tên anh hùng làm tiền tố, như “SonaQ”, “ChamberE” hoặc “AshUlt”. Ví dụ: trong League of Legends có các hàm như “DragonEffect”, “TowerEffect” và “Q_Effects”, chứa nhiều điều kiện và được sử dụng bởi nhiều meter. Cách đặt tên này do đó cũng giúp tối ưu hóa cho khả năng mở rộng.

Đừng mắc lỗi chính tả. Nếu không chắc về cách đánh vần, hãy tra cứu. Tên phải rõ ràng và dễ đọc, bất kể ai đang làm việc trên code hoặc đã qua bao nhiêu thời gian. Sắp xếp tên theo thứ tự bảng chữ cái giúp tìm kiếm nhanh, đặc biệt khi phần này được chỉnh sửa thường xuyên. Mặc dù mức độ tổ chức này không cần thiết để thực thi code, nó tạo ra sự khác biệt lớn cho các nhà phát triển bảo trì.