Hôm nay mình vừa đọc một bài viết phân tích kiến trúc gameplay và đồng bộ mạng của Overwatch. Đây là bản chuyển ngữ từ bài thuyết trình “Overwatch Gameplay Architecture and Netcode” tại hội nghị GDC 2017. Vì không có bản gốc tiếng Anh nên mình phải xem đi xem lại video gốc trên GDC Vault tận 3 lần mới hiểu rõ được mô hình ECS (Entity-Component-System). Bài viết này sẽ ghi lại những hiểu biết của mình về ECS, kết hợp với kinh nghiệm phát triển game hơn 10 năm qua, có thể sẽ có điểm khác biệt so với bài giảng gốc.

Skynet là một framework được thiết kế để xử lý nhiệm vụ song song hiệu quả, tận dụng tối đa sức mạnh của CPU đa nhân cho các nghiệp vụ tiêu tốn tài nguyên và có khả năng song hành tự nhiên như game online. Trong thiết kế ban đầu, I/O mạng không phải là trọng tâm tối ưu hóa.

Xuất phát từ định hướng này, tầng mạng của skynet được triển khai theo mô hình đơn luồng. Lý do là bởi theo quan điểm của tôi, một chương trình đơn luồng với lượng mã lớn vẫn dễ hiểu và ít bug hơn chương trình đa luồng dù có lượng mã ngắn hơn. Những ứng dụng mạng kinh điển như Redis hay Nginx đã chứng minh rằng xử lý mạng đơn luồng không nhất thiết kém hiệu quả, thậm chí còn tạo được tiếng vang lớn nhờ tính ổn định.

Một đồng nghiệp gần đây đã gặp phải một yêu cầu thú vị: cần thường xuyên truyền một nhóm dữ liệu qua mạng trong hệ thống skynet, tuy nhiên thực tế dữ liệu này thay đổi không thường xuyên. Điều này dẫn đến việc lặp lại quá trình tuần tự hóa và truyền tải một cách không hiệu quả.

Để cụ thể hơn, anh ấy đã thiết kế một nút cổng trong skynet, với nhiệm vụ chính là phát tán thông điệp đến nhóm khách hàng qua giao tiếp nội bộ. Mỗi khách hàng được nhận diện bằng một chuỗi UUID đặc biệt, trong khi mỗi thông điệp đều mang theo danh sách UUID các khách hàng cần nhận. Tuy nhiên, các danh sách này có mức độ trùng lặp rất cao - cùng một danh sách UUID bị đóng gói lặp đi lặp lại trong từng lần phát tán.

Vài ngày trước, một sản phẩm đang vận hành đã gặp sự cố sụp đổ nghiêm trọng. Tôi đã dành hai ngày để phân tích coredump bằng gdb, dù không thể tìm ra nguyên nhân gốc rễ nhưng vẫn muốn tổng hợp lại những kinh nghiệm thu được.

Sản phẩm này được xây dựng trên nền tảng skynet, nhưng do lý do lịch sử nên đang sử dụng phiên bản giữa năm 2015 (trước cả skynet 1.0). Hai năm qua không gặp vấn đề gì nên đội ngũ bảo trì lơ là việc cập nhật phiên bản mới.

Một vấn đề thiết kế của epoll
Vấn đề bắt nguồn từ một yêu cầu trên hệ thống Skynet, trong đó một luồng socket rơi vào vòng lặp vô hạn do một file descriptor (fd) liên tục tạo ra các sự kiện mới. Điều đặc biệt là các sự kiện này không thuộc loại EPOLLIN hay EPOLLOUT thông thường, dẫn đến việc gọi lặp vô tận hàm epoll_wait và làm CPU hoạt động ở mức 100%.

Trong một cuộc trò chuyện ngẫu hứng hôm qua, chúng tôi đã thảo luận về mô hình truyền thông mạng nên áp dụng cho client MMORPG. Dù đã từng viết về chủ đề này từ lâu, nhưng dường như bài viết đã thất lạc somewhere. Nhân dịp này, tôi xin trình bày lại quan điểm của mình một cách hệ thống.

Theo tôi, trong các game MMO, server đóng vai trò là thế giới ảo trung tâm - nơi mọi trạng thái và sự thay đổi đều được xác định và cập nhật bởi hệ thống. Client, ngược lại, bản chất là một “trình hiển thị trạng thái” - có nhiệm vụ phản ánh chính xác những gì người chơi nhìn thấy trong thế giới ảo thông qua các gói tin mạng. Chính vì vậy, khi thiết kế hệ thống xử lý tin nhắn mạng cho client, chúng ta cần lấy vai trò này làm trung tâm.