Thiết kế lưới đồ họa trên bề mặt cầu.

Thiết kế lưới đồ họa trên bề mặt cầu.

Thiết kế lưới bản đồ hình cầu
Trong vài năm trở lại đây, các trò chơi sử dụng bản đồ hình cầu ngày càng phổ biến, tiêu biểu là Dự án Vòng Đai Dyson - tựa game được đánh giá cao trong năm nay.

Đa số game xây dựng trên bề mặt cầu đều ưa chuộng lưới hình lục giác đều. Tuy nhiên, nếu chỉ dùng duy nhất lục giác đều sẽ không thể phủ kín mặt cầu. Lý do là vì luôn tồn tại 12 điểm khiếm khuyết hình ngũ giác. Điều này bắt nguồn từ nguyên lý hình học: việc lát gạch lục giác trên cầu thực chất là mô phỏng hình đa diện 20 mặt đều (icosahedron). Khi triển khai mặt phẳng của khối 20 mặt đều, mỗi mặt tam giác đều sẽ được chia nhỏ thành nhiều tam giác nhỏ hơn. Khi ghép 6 tam giác lại thành một lục giác, ở 12 vị trí đặc biệt sẽ xuất hiện các điểm giao thoa gồm 5 tam giác - tạo thành ngũ giác. Chỉ cần xử lý khéo léo các điểm khiếm khuyết này, lưới lục giác vẫn là lựa chọn tối ưu.

Hiện tại, bé lớn Đậu Mây đã 7 tuổi, bé nhỏ Ca Ca 4 tuổi rưỡi. Tôi đã thử chơi board game cùng các con từ ba năm trước, nhưng thực tế chỉ có vài trò chơi thực sự thành công. Gần đây, Đậu Mây bước vào giai đoạn bùng nổ hứng thú với trò chơi bàn. Cậu bé thậm chí tự mình nghiên cứu chiến thuật mà không cần tôi gợi ý, điều này thật đáng ghi nhận.

Trong quá trình duy trì bản mod dịch tiếng Việt cho trò chơi Stellaris, tôi đã dành nhiều thời gian nghiên cứu hệ thống ngôn ngữ kịch bản độc đáo của Paradox. Đây là một hệ thống vừa tinh tế vừa phức tạp, kết hợp giữa cấu trúc dữ liệu thuần túy với khả năng điều khiển logic trò chơi.

Tôi nhận thấy mô hình này có nhiều điểm tương đồng với cách tiếp cận của ngôn ngữ LISP, khi sử dụng cấu trúc dữ liệu để mô tả logic trò chơi. Các game của Paradox đều có kho kiến thức khổng lồ trên wiki cộng đồng, cung cấp tài nguyên phong phú cho các modder. Khả năng học hỏi hệ thống này rất cao nhờ cơ chế trực quan và nhất quán trong thiết kế.

Trong quá trình phát triển dự án bằng engine tự xây dựng, gần đây tôi đã gặp phải một số vấn đề cần giải quyết. Trong quá trình khắc phục, thiết kế ban đầu cũng được điều chỉnh theo hướng tối ưu hơn. Từ những sửa đổi nhỏ ban đầu, dần dần tiến triển thành một cuộc tái cấu trúc mã quy mô lớn.

Khởi nguồn từ việc tôi thiết kế lại khung làm việc ECS. Trong thiết kế mới, có thể kết hợp C/Lua để tổ chức dữ liệu, tạo tiền đề cho việc tối ưu hiệu năng trong tương lai. Dịp này cũng giúp chúng tôi xem xét lại cách tổ chức mã trong khung ECS. Một điểm mấu chốt được nhận ra: cần loại bỏ tối đa mối quan hệ tham chiếu giữa các đối tượng trong hệ thống. Mỗi loại đối tượng nên được xử lý theo nhóm, mỗi module chỉ thực hiện công việc đơn giản nhất có thể, nhưng xử lý đồng thời lượng dữ liệu lớn nhất.

Vấn đề căn chỉnh bộ nhớ và tối ưu hóa trình biên dịch
Hôm qua, trên nhóm nội bộ công ty mang tên “Tự rước họa vào thân” (dành cho các lập trình viên), có thành viên đã chia sẻ một bài viết trên Zhihu. Điều khiến anh ấy ngạc nhiên là vấn đề hóa ra lại được giải quyết bằng cách tắt chức năng builtin-memset của GCC, một cách vô cùng huyền bí.

Gần đây, tôi đã thực hiện buổi chia sẻ kéo dài 2 tiếng tại công ty, trình bày về những suy nghĩ và kinh nghiệm áp dụng mô hình ECS trong vài năm gần đây. Chủ đề tôi chọn không phải là “ECS” mà là một khái niệm rộng hơn mang tên “Thiết kế định hướng dữ liệu”. Lý do là bởi tôi muốn tránh bị gò bó vào các thuật ngữ cụ thể như Entity Component System. Theo Wikipedia, DOD (Data-Oriented Design) ra đời từ nhu cầu tối ưu hiệu năng trong phát triển game, tập trung vào cách tổ chức dữ liệu trong bộ nhớ. So với cách bố trí mặc định của các ngôn ngữ lập trình hướng đối tượng như C++, mô hình DOD/ECS tối ưu hơn trong việc tận dụng CPU Cache nhờ cách sắp xếp dữ liệu thông minh, từ đó mang lại hiệu suất vượt trội.