Optimizing Deep Rock Galactic Survivor for mobile

Cần những gì để đưa một tựa game PC phức tạp lên nền tảng di động cho người chơi? Trò chơi Funday Deep Rock Galactic: Người sống sót Trò chơi kết hợp lối chơi bắn súng liên tục với các nhân vật người lùn, các lớp nhân vật, vũ khí và cơ chế đào bới của Deep Rock Galactic . Thách thức đối với công ty chuyển đổi game Piktiv là quản lý hàng ngàn kẻ thù và thành phần môi trường được mô phỏng đồng thời trong khi vẫn duy trì tốc độ khung hình ổn định trên phần cứng với ngân sách GPU, CPU và bộ nhớ hạn chế.

Để mang lại trải nghiệm đó trên thiết bị di động, cần phải làm lại các hệ thống có chi phí tăng theo số lượng kẻ thù: tìm đường đi, truy vấn vật lý, hiển thị kẻ thù, tính toán sát thương và hiển thị môi trường. Nhóm phát triển cũng phải điều chỉnh trò chơi sao cho phù hợp với iPad 3 GB, hỗ trợ nhiều thiết bị khác nhau, từ các dòng điện thoại cao cấp hiện nay đến các thiết bị Android đời cũ, và duy trì sự kết nối một chiều với nhánh PC vẫn đang được phát triển tích cực.

Chúng tôi đã trao đổi với quản lý kỹ thuật Marcus Ekelund và kỹ sư trưởng Fredrik Åkerblom về việc chuyển đổi hệ thống. Deep Rock Galactic: Người sống sót đến thiết bị di động, các giải pháp tùy chỉnh của họ và cách họ tối ưu hóa hiệu năng trên một hệ sinh thái thiết bị phân mảnh.

Những mục tiêu kỹ thuật hàng đầu của bạn khi bắt đầu dự án chuyển đổi sang nền tảng di động là gì?

Fredrik Åkerblom: Nhiều mục tiêu kỹ thuật mà chúng tôi đặt ra ngay từ đầu chỉ đơn giản là: Liệu chúng ta có thể chạy ứng dụng này trên thiết bị di động hay không, và chúng ta có thể hỗ trợ được bao nhiêu thiết bị? Nếu bạn nhìn vào các sản phẩm Apple , bạn sẽ thấy không có nhiều tùy chọn về độ chi tiết khi giao hàng. Có những sản phẩm hiện đại nhất, sau đó là một danh mục rộng hơn bao gồm nhiều sản phẩm hiện có trên thị trường, và cuối cùng là tất cả những thứ còn lại. Bạn cần đạt ít nhất mức trung bình.

Một trong những vấn đề thường xuyên xảy ra với chúng tôi là tất cả các thiết bị đó đều có 4 GB RAM, ngoại trừ một chiếc iPad chỉ có 3 GB. Vì vậy, điều đó đã trở thành mục tiêu kỹ thuật cốt lõi: Liệu chúng ta có thể chạy ứng dụng này trên iPad mà không bị lỗi không? Chúng tôi có khoảng 1.850 MB dung lượng để sử dụng, và nếu vượt quá giới hạn đó, mọi chuyện sẽ kết thúc. Phần lớn công việc ban đầu chỉ tập trung vào việc tối ưu hóa RAM, và sau đó chúng tôi mới có thể xem xét kỹ hơn hiệu năng thực tế của trò chơi trên các nền tảng khác nhau. Mặt khác, Android hiện có khoảng 9.000 thiết bị khác nhau, vì vậy việc đảm bảo mọi thứ hoạt động tốt trên đó là cả một lĩnh vực nghiên cứu riêng.

Những trở ngại lớn nhất về hiệu năng mà bạn gặp phải khi chuyển từ PC sang phần cứng di động là gì, và bạn đã khắc phục chúng như thế nào?

FÅ: Có một vài hệ thống cốt lõi thực sự nổi bật, và đó là những hệ thống có hàng nghìn đối tượng hoạt động: Các chỉ số sát thương, đạn đạo, thế giới trong game và cả những kẻ thù 3D được hoạt họa.

Ví dụ, các đoạn văn bản hiển thị sát thương ban đầu là một GameObject sử dụng TextMesh Pro . Nhưng khi bạn có cả nghìn kẻ thù trên màn hình và bạn ném lựu đạn vào chúng, tất cả chúng đều cần hiển thị số sát thương. Điểm nghẽn nằm ở việc tạo ra lưới văn bản: Sử dụng phông chữ để chuyển đổi chuỗi ký tự của bạn thành hình ảnh trực quan.

Cuối cùng, chúng tôi đã sử dụng hệ thống hạt thông thường Unity với một bảng hình ảnh các số từ 0 đến 9.

ME: Một ví dụ khác là việc tìm đường đi cho tất cả kẻ thù, sử dụng hệ thống NavMesh tích hợp sẵn trên PC. Chúng tôi cũng có một nhóm kỹ sư từ Unity hỗ trợ, và một trong số họ bắt đầu nghiên cứu một giải pháp sử dụng điều hướng trường dòng chảy. Một kỹ sư khác đã xây dựng giải pháp cây KD để tối ưu hóa và loại bỏ nhiều truy vấn vật lý.

FÅ: Với việc hiển thị kẻ thù, chúng ta có khoảng một nghìn mô hình lưới được tạo hình trên màn hình cùng một lúc, và điều đó thực sự không hiệu quả. Thực tế thì, hầu hết các kẻ thù này đều chỉ có một hoạt ảnh duy nhất, vì vậy chúng ta thực sự không cần hỗ trợ nhiều hoạt ảnh khác nhau.

Thay vào đó, phương pháp này sử dụng một hệ thống trong đó mỗi khung hình chính của hoạt ảnh được tích hợp vào một texture. Chúng tôi xử lý từng khung hình như vậy, và sau đó tất cả chúng đều được tạo hoạt ảnh đỉnh bằng một shader trên GPU, vì vậy hầu như không tốn tài nguyên CPU.

Việc nén nó thành một lưới tĩnh duy nhất và một kết cấu là một cải tiến lớn, và nó cũng cho phép bạn thực hiện những việc như tạo bản sao GPU , vì về mặt kỹ thuật, chúng đều là cùng một lưới với cùng một chất liệu.

Các trường dòng chảy và cây KD hoạt động như thế nào bên trong, và chúng đã thay thế những gì?

FÅ: Trường dòng chảy là sự đảo ngược của vị trí chi phí trong quá trình tìm đường đi. Thông thường, khi bạn có 20 hoặc 30 tác nhân tìm đường đi trong một môi trường, bạn sẽ tạo một lưới (mesh) của môi trường đó và mỗi tác nhân sẽ tự chịu trách nhiệm tìm đường đi cho riêng mình. Khi có hàng nghìn tác nhân, điều đó sẽ tạo ra một nút thắt cổ chai khá lớn, bởi vì chi phí có xu hướng tăng theo số lượng tác nhân.

Bạn tạo một lưới bao phủ toàn bộ màn chơi, sau đó bắt đầu từ vị trí mục tiêu, và tất cả các ô xung quanh sẽ vẽ một mũi tên chỉ về phía mục tiêu. Tiến thêm một bước, hướng mũi tên về phía vật gần nhất đã có mũi tên, và tiếp tục như vậy cho đến khi bạn đã bao phủ toàn bộ khu vực. Vì vậy, thay vì tính phí cho mỗi tác nhân, chi phí được tính dựa trên kích thước của khu vực bạn muốn tìm đường đi bên trong.

Bạn cũng có thể giới hạn điều đó hơn nữa. Chúng tôi tính toán dựa trên vị trí của kẻ thù, vì vậy chúng tôi tạo một khung bao quanh chứa tất cả kẻ thù cộng với người chơi, và chúng tôi chỉ cập nhật không gian bên trong khung đó.

Đối với các truy vấn không gian, chúng tôi đã sử dụng cây KD. Nếu bạn có một căn phòng lớn và kẻ một đường thẳng xuống giữa phòng, bạn đột nhiên chia nó thành hai không gian. Bạn tạo một cấu trúc cây mà bạn có thể truy vấn khá dễ dàng: Đây là một điểm và một bán kính, hãy cho tôi bất cứ thứ gì nằm trong phạm vi đó.

Điều đó có thể thay thế nhiều truy vấn vật lý phức tạp hơn, chẳng hạn như khi một quả lựu đạn phát nổ và tôi cần tìm tất cả kẻ thù trong vòng tròn này. Tôi không chắc cuối cùng nó có hoàn toàn phù hợp hay không, bởi vì cây KD cần phải được tái tạo rất nhiều — kẻ thù liên tục di chuyển, vì vậy cây KD phải được xây dựng lại thường xuyên.

Bạn đã tiếp cận việc thử nghiệm và tinh chỉnh trên các thiết bị di động như thế nào?

FÅ: Một trong những việc đầu tiên chúng tôi làm là xác định một thiết bị mà chúng tôi cho rằng trò chơi có thể chạy được – một thiết bị thuộc phân khúc tầm thấp nhưng chúng tôi muốn đạt được ít nhất 30 khung hình/giây.

Chúng tôi đã xây dựng một hệ thống đo lường hiệu suất tự động, cho phép thiết lập một loạt các kịch bản khác nhau. Chúng tôi đã thực hiện tổng cộng sáu kịch bản trong Deep Rock Galactic: Người sống sót . Chúng ta có thể xây dựng trò chơi cụ thể theo chế độ đo lường này, và ngay khi khởi chạy trên thiết bị, nó sẽ đi vào một môi trường sinh thái và chạy sáu kịch bản đó.

Một kịch bản có thể là người chơi đứng yên, sau đó chúng tôi tạo ra hàng nghìn kẻ thù di chuyển về phía bạn, hoặc chúng tôi tạo ra 500 kẻ thù và trang bị cho bạn tất cả các loại vũ khí này rồi tự động bắn theo mọi hướng. Điều đó giúp chúng ta có cái nhìn tổng quan về những gì đang diễn ra, và chúng ta đo CPU, GPU, bộ nhớ – hầu như bất cứ thứ gì chúng ta có thể đo được. Chúng tôi chạy thử nghiệm trên tất cả các quần xã sinh vật để xem liệu có quần xã nào gặp vấn đề về hiệu suất cụ thể hay không.

Unity Profiler là một trong những công cụ chính của chúng tôi để kiểm tra hiệu năng CPU, đặc biệt là trong giai đoạn đầu khi chúng tôi đang tìm kiếm những cải tiến dễ thực hiện và mang lại lợi ích lớn nhất.

Addressables đã hỗ trợ quản lý nội dung và dung lượng bộ nhớ cho thiết bị di động như thế nào?

FÅ: Addressables) là một phần quan trọng dẫn đến việc đạt đến giới hạn bộ nhớ 3 GB trên iPad. Nhìn chung, chúng tôi đã tách riêng những phần có vẻ đơn giản ngay từ đầu. Ví dụ, bạn sẽ không bao giờ ở trong nhiều hơn một quần xã sinh vật cùng một lúc, vì vậy bạn có thể tách riêng tất cả các tài nguyên đồ họa và cài đặt đó.

Addressables đưa hành vi bất đồng bộ vào một hệ thống trước đây hoàn toàn đồng bộ, và việc xây dựng lại toàn bộ hệ thống thành bất đồng bộ có thể là một thách thức kiến ​​trúc khá lớn, tùy thuộc vào trò chơi của bạn. Nhưng trong trường hợp này, nó lại là lựa chọn phù hợp nhất với chúng tôi.

Bạn đã theo dõi những chỉ số hiệu suất nào để đo lường sự thành công của phiên bản di động?

FÅ: Hầu hết các mục tiêu của chúng tôi đều liên quan đến hiệu suất: Trên các mẫu máy này, chúng tôi muốn đạt được 30 khung hình/giây, còn trên các mẫu máy cao cấp nhất, chúng tôi kỳ vọng đạt được 60 khung hình/giây.

TRONG Deep Rock Galactic: Người sống sót Mỗi khi bạn tiêu diệt một con côn trùng, một loạt các khối lập phương màu xanh sáng bóng sẽ xuất hiện, bạn có thể nhặt chúng để lên cấp. Một trong những kịch bản đo lường tự động của chúng tôi đã tạo ra khoảng 4.000 mục như vậy trong vòng 10 giây, và điều đó đã gây ảnh hưởng nghiêm trọng đến hiệu năng ngay từ giai đoạn đầu. Sau khi chúng tôi thực hiện tối ưu hóa ban đầu, kết quả không còn đo lường được nữa.

Việc tối ưu hóa chuyển động và vật lý của kẻ thù cũng đã nâng cao đáng kể mức khung hình tối thiểu. Điều đó dẫn đến việc hình thành các trường dòng chảy, cũng như một chuỗi dài các tác vụ Burst – với 10 hoặc 15 mối phụ thuộc – chịu trách nhiệm di chuyển tất cả kẻ thù, tất cả đều nằm ngoài hệ thống vật lý thông thường.

Trò chơi này tạo ra các cấp độ theo thuật toán, vì vậy tầng trệt và tất cả các bức tường đều được xây dựng từ các đối tượng riêng lẻ. Vì chúng ta có camera nhìn từ trên xuống với cùng một góc độ mọi lúc, chúng ta có thể dễ dàng tính toán khung hình mà chúng ta có thể nhìn thấy các vật thể, thu thập tất cả các đối tượng đó và gửi chúng đến trình kết xuất thông qua các lệnh vẽ hàng loạt của riêng chúng ta. Đây là một cải tiến lớn cho cả GPU và CPU, bởi vì việc gửi tất cả các lệnh vẽ đó một cách riêng lẻ sẽ tiêu tốn khá nhiều tài nguyên CPU.

Bạn có lời khuyên hàng đầu nào dành cho các nhà phát triển muốn chuyển game PC của họ lên di động không?

ME: Vấn đề không phải là tìm ra một giải pháp thần kỳ duy nhất, mà luôn là sự hợp tác giữa các hệ thống khác nhau.

FÅ: Chi phí cho việc chuyển dữ liệu ra vào các thành phần khác nhau thực sự bắt đầu tăng lên khi bạn xử lý hàng nghìn thực thể mỗi khung hình. Nếu bạn có thể quản lý dữ liệu của mình sao cho tất cả dữ liệu đều nằm trong các container gốc và bạn sử dụng cùng một container gốc đó trong toàn bộ quy trình, bạn có thể kiếm được rất nhiều tiền từ đó.

ME: Một bài học khác rút ra từ dự án này: Giả sử bạn có một trò chơi và sau khi hoàn thành, bạn nhận ra rằng lẽ ra bạn nên xây dựng nó bằng ECS ​​cho Unity , hoặc bất kỳ hệ thống nào thuộc Data-Oriented Technology Stack (DOTS) . Bạn không cần phải chuyển đổi toàn bộ trò chơi của mình và viết lại từ đầu. Chúng tôi chỉ sử dụng trình biên dịch Burst và rất nhiều kiểu dữ liệu gốc.

Deep Rock Galactic: Người sống sót Hiện có sẵn trên Steam, Xbox , App Store và Google Play . Hãy xem thêm các bài viết từ các nhà phát triển Unity trên Blog và Trung tâm Tài nguyên Unity .