Hôm nay, một đồng nghiệp hỏi rằng liệu có thể không dừng tiến trình Skynet mà vẫn tải lại một dịch vụ Lua được không.
Câu trả lời ngắn gọn là không thể. Nhưng nếu phân tích kỹ hơn, việc này không hoàn toàn bất khả thi, tuy nhiên người dùng cần tự xây dựng cơ chế phù hợp dựa trên Skynet.

Vấn đề này liên quan đến cập nhật nóng (hot update) dịch vụ. Trong Lua, hàm là đối tượng hạng nhất (first-class), điều này vừa là lợi thế vừa là thách thức. Dù dễ dàng thay thế hàm, nhưng việc cập nhật lại phụ thuộc vào cách người dùng tổ chức mã nguồn.

Bài viết này được chia thành ba phần chính: thứ nhất, phân tích các trường hợp nên sử dụng giao thức UDP thay vì TCP; thứ hai, thiết kế giao diện API cho một mô-đun truyền tải UDP đáng tin cậy; và cuối cùng là một bản triển khai đơn giản.

Khi nào nên ưu tiên UDP thay vì TCP?

Tôi luôn cho rằng việc xây dựng một giao thức truyền tải đáng tin cậy trên nền UDP (ví dụ như mô phỏng TCP trên UDP) là một ý tưởng không khả thi. TCP đã là một giao thức cực kỳ phức tạp, và gần như không thể tái tạo hiệu quả hơn. Nếu cố gắng xây dựng một giao thức UDP đáng tin cậy nhưng hiệu suất vượt trội TCP, kết quả thường chỉ khả quan trong một số tình huống cụ thể, hoặc tệ hơn là chiếm dụng quá nhiều tài nguyên mạng. TCP được thiết kế với tiêu chí tối ưu hóa lưu lượng toàn mạng, trong khi các giao thức “ích kỷ” cố gắng chiếm băng thông sẽ dẫn đến nghẽn mạng toàn hệ thống.

Lõi của skynet không quy định cụ thể cách xử lý luồng dữ liệu TCP. Tuy nhiên trong phát triển game mạng, chúng ta thường tuân theo quy tắc chia luồng dữ liệu thành từng gói tin riêng biệt thông qua kết nối TCP. Phương pháp phổ biến để chuyển đổi luồng dữ liệu thành các gói tin riêng lẻ là thêm thông tin độ dài gói vào luồng dữ liệu. Tôi đặc biệt khuyến khích việc sử dụng 2 byte để biểu diễn độ dài gói. Skynet cung cấp một khuôn mẫu GateServer để hỗ trợ triển khai cổng kết nối này.

Trong dịp Tết trở về nhà ở Vũ Hán, tôi chỉ có duy nhất một chiếc máy tính tích hợp giá khoảng 2000 nhân dân tệ để sử dụng. Chắc chắn rồi, chiếc máy này không thể chạy nổi các game 3D. Tôi chọn thử tựa game Invisible Inc. và thật bất ngờ, game chạy rất mượt mà.

Đây là một game chiến thuật theo phong cách XCOM với bối cảnh được thiết kế theo kiểu isometric. Điều đặc biệt là người chơi có thể xoay cảnh bằng phím Q và E. Dù khi dừng lại chỉ có 4 hướng cố định, nhưng quá trình xoay lại được thể hiện dưới dạng hoạt ảnh. Điều này khiến tôi ban đầu nghĩ rằng cảnh game được xây dựng từ mô hình 3D. Tuy nhiên, điều khiến tôi ngạc nhiên là trên chiếc máy cấu hình yếu này, game vẫn chạy mượt mà hơn nhiều so với XCOM 2 - tựa game tôi đang chơi trên card đồ họa GTX 550.

Vấn đề OpenGL cũ này đã xuất hiện từ lâu, nhưng nhiều thành viên trong công ty liên tiếp gặp phải nên rất cần lưu lại tài liệu. Việc này sẽ giúp tăng khả năng tìm thấy thông tin khi tra cứu trên Google, và hy vọng sẽ không có lần thứ ba nào nữa.

Ban đầu tôi cho rằng sau khi bind VBO trong OpenGL, nếu dữ liệu VBO thay đổi thì không cần bind lại đối tượng VBO. Vì vậy trong phiên bản cũ của ejoy2d, chúng tôi đã thực hiện một số tối ưu hóa tại đây - bỏ qua việc bind lặp để giảm bớt số lần gọi API.

Trong hệ thống ejoy2d, tôi lưu trữ thông tin cấu trúc của các sprite trong một cấu trúc gọi là “gói sprite”. Cấu trúc này bao gồm dữ liệu frame của hoạt ảnh, các thành phần tạo nên sprite, ma trận biến đổi của từng phần, mã hoá và toạ độ texture tương ứng… Những dữ liệu này thường không chiếm quá lớn, vì vậy tôi đề xuất giải pháp nạp toàn bộ vào bộ nhớ một lần và không xóa chúng ra khỏi RAM. Các đối tượng sprite được tạo động sẽ tham chiếu trực tiếp đến các dữ liệu này mà không cần đếm số lần tham chiếu. Việc tham chiếu chéo giữa các dữ liệu (tương tự như lắp ghép lego, dùng nhiều mảnh ghép nhỏ để tạo thành sprite phức tạp) cũng không cần ghi nhận thêm thông tin.