Trong trò chơi mà chúng tôi đang phát triển, hệ thống giao thông và hậu cần vận hành dựa trên mạng lưới đường bộ. Về bản chất, mạng đường bộ là một đồ thị vô hướng với các giao lộ đóng vai trò đỉnh và các đoạn đường là cạnh nối giữa chúng. Do số lượng phương tiện di chuyển trên mạng cực kỳ lớn, chúng tôi cần một phương pháp lưu trữ lộ trình của các xe này sao cho tối ưu về mặt không gian.
Ltask là một thư viện có chức năng tương tự như Skynet, nhưng được thiết kế chủ yếu để hoạt động trong môi trường client. Vì ra đời sau Skynet, tôi đã thử nghiệm nhiều ý tưởng mới trên nền tảng này.
Gần đây, tôi gặp phải một yêu cầu đặc biệt: một số module C/C++ của bên thứ ba được tích hợp vào engine game của chúng tôi cung cấp các giao diện thông qua cơ chế callback. Khi nhúng các module này vào các dịch vụ của ltask, các hàm callback này không thể tận dụng đầy đủ các tính năng của ltask. Ví dụ, toàn bộ thao tác IO trong hệ thống đều được xử lý bởi một dịch vụ độc lập. Khi engine đọc file, dữ liệu có thể được tải từ xa qua mạng theo cơ chế bất đồng bộ. Tuy nhiên, các module bên thứ ba thường không thiết kế để xử lý IO bất đồng bộ, mà chỉ cung cấp các hàm callback đọc file theo kiểu đồng bộ để người dùng tự triển khai.
Chúng tôi đang phát triển một trò chơi xoay quanh tự động hóa tương tự như Factorio. Trong quá trình phát triển, chúng tôi gặp phải nhiều vấn đề thuật toán thú vị và giải quyết chúng theo những cách rất sáng tạo. Trước đây tôi đã từng viết một bài về hệ thống chất lỏng, ví dụ như vậy.
Điểm khác biệt lớn nhất so với trải nghiệm Factorio nằm ở việc chúng tôi không sử dụng băng chuyền làm phương thức vận chuyển chính, mà thay vào đó xây dựng một hệ thống đường bộ và xe tải. Cách tiếp cận này không mới, từ hơn 20 năm trước trong tựa game Caesar III (cùng loạt với Pharaoh, Zeus và Rise of Nations) tôi đã từng trải nghiệm. Các trò chơi theo mô hình này chưa bao giờ biến mất khỏi thị trường, vài năm gần đây tôi đã chơi qua các tựa như Banished, Don’t Starve, RimWorld hay Beaver Fever - tất cả đều áp dụng cách vận chuyển tương tự.
Một đồng nghiệp vừa chia sẻ với tôi bài viết về vấn đề Go xử lý lượng lớn thao tác giải mã JSON/Protobuf song song, dẫn đến việc sinh ra hàng chục gigabyte (10GB) bộ nhớ tạm thời không thể thu hồi kịp thời. Tôi cho rằng đây là vấn đề cần được tiếp cận từ góc độ thiết kế hệ thống cơ bản.
Khi một module hệ thống có khả năng tiêu tốn 10GB RAM, đó chắc chắn là vấn đề trọng tâm cần được xử lý đặc biệt. Đây không phải là lỗi của Garbage Collector hay bằng chứng cho sự bất lực của lập trình viên trong việc quản lý bộ nhớ thủ công. Ngay cả khi tự quản lý heap, bạn vẫn đối mặt với bài toán phân mảnh bộ nhớ, lãng phí tài nguyên do phải duy trì các cấu trúc dữ liệu quản lý vùng nhớ phức tạp. Giải pháp tối ưu không nằm ở việc chuyển giao gánh nặng quản lý bộ nhớ, mà phải bắt đầu từ việc đơn giản hóa cấu trúc dữ liệu.
Trong quá trình thiết kế luaecs vào năm ngoái, một vấn đề còn tồn đọng là cơ chế tham chiếu entity cụ thể. Ban đầu tôi cho rằng hệ thống tag linh hoạt có thể giải quyết phần lớn nhu cầu, hoặc người dùng có thể tự xây dựng component ID 64-bit kèm thuật toán tìm kiếm nhị phân. Tuy nhiên đến đầu năm nay, qua quan sát cả người dùng nội bộ và bên ngoài, tôi nhận ra nhu cầu tham chiếu trực tiếp đến entity là không thể tránh khỏi. Điều này dẫn đến việc phát triển giải pháp tham chiếu phi xâm nhập mới.
Động cơ game của chúng tôi sử dụng RmlUI để xây dựng giao diện người dùng (GameUI). Mục tiêu của tôi là tận dụng CSS - một ngôn ngữ đã được chứng minh hiệu quả trong việc mô tả giao diện trực quan, kết hợp phương pháp phát triển frontend web để thiết kế UI game. Tuy nhiên, tôi không muốn tích hợp một engine rendering web phức tạp, đồng thời nhu cầu của game cũng có nhiều điểm khác biệt. Vì vậy, tôi chọn RmlUI - một giải pháp nhẹ và linh hoạt. Để đồng bộ với ngôn ngữ phát triển chính của game, chúng tôi sử dụng Lua thay vì JavaScript để điều khiển CSS.