SEED kết xuất một thế giới mà người chơi không bao giờ ngừng xây dựng

Bạn không thể đoán được các cầu thủ sẽ xây dựng gì. Trong SEED, đó là toàn bộ ý nghĩa – và thách thức kết xuất cốt lõi.

SEED là sandbox MMO bền vững của Klang Games, được xây dựng bằng Unity. Nó được đặt trên một hành tinh xa xôi nơi người chơi quản lý các nhân vật tự trị gọi là cây con, xây dựng nhà cửa và doanh nghiệp, giao dịch trong một Economy do người chơi điều khiển, và tổ chức các xã hội với vai trò và luật lệ riêng của họ. Thế giới tiếp tục vận hành sau khi người chơi đăng xuất, và nó không ngừng phát triển. Mỗi ngôi nhà, cửa hàng, cây và cây con mới đều gây thêm áp lực lên hiệu suất kết xuất Unity, trên các phần cứng từ máy tính cao cấp đến điện thoại.

Bản mô phỏng tự chạy trên máy chủ của Klang Games. Nhiệm vụ của máy khách Unity là hiển thị bất kỳ trạng thái nào mà máy chủ truyền vào, vì vậy khối lượng công việc của nó phụ thuộc vào những gì người chơi đã xây dựng, chứ không phụ thuộc vào những gì đội đã lên kế hoạch.

“Vì SEED là một trò chơi hoàn toàn do máy chủ quản lý, máy khách chủ yếu đọc và hiển thị trạng thái và chuyển tiếp các tương tác của người chơi, như nhấp chuột hoặc di chuyển camera,” Artem Dyadichkin, kỹ sư đồ họa tại Klang Games, cho biết.

Chúng tôi đã nói chuyện với Dyadichkin và Nikita Fetisov, kỹ sư game cao cấp, về việc kết xuất các xã hội do người chơi xây dựng bằng Universal Render Pipeline (URP), giữ cho hàng nghìn vật thể nhỏ rẻ, và sử dụng dữ liệu người chơi thực để tìm điểm nghẽn trên PC và di động.

Một thế giới được xây dựng từ những mảnh nhỏ

Phong cách nghệ thuật của SEED thực hiện phần lớn công việc mở rộng trước khi bất kỳ mã nào chạy. Trò chơi được cách điệu và đa giác thấp, và thay vì dựa vào các kết cấu, nó lưu trữ hầu hết dữ liệu bề mặt của nó trong hình học.

"Hầu hết dữ liệu màu của chúng tôi thực sự được lưu trữ bên trong dữ liệu đỉnh," Dyadichkin nói. "Dữ liệu đỉnh biết nó có màu gì, nó có định nghĩa vật liệu nào – nó là kim loại, nó có mịn không?" Tất cả những thứ đó đều được nhúng sẵn vào các lưới.

Điều đó giúp tiết kiệm về đổ bóng và băng thông bộ nhớ, điều này quan trọng nhất trên thiết bị di động.

Các tòa nhà áp dụng cách tiếp cận đó đến mức cực đoan. Thay vì coi mỗi cấu trúc là một lưới lớn duy nhất, SEED xây dựng các tòa nhà từ nhiều mô-đun nhỏ giống như gạch: tường, sàn, các cạnh mái và các góc trên lưới một mét. Người chơi đặt các khối xây dựng thô (voxel), và trò chơi mở rộng mỗi khối thành khoảng 15 mô-đun, với khoảng một nửa tạo thành ngoại thất của tòa nhà và một nửa là nội thất, chỉ được tạo ra khi người chơi nhìn vào bên trong. Xã hội lớn nhất trên một trong những hòn đảo bận rộn nhất của SEED có 172 tòa nhà, bao gồm khoảng 12.500 voxel, hay 190.000 mô-đun.

“Chúng tôi sử dụng BatchRendererGroup để kết xuất chúng và nhóm chúng lại với nhau, và chúng tôi thực hiện các nhóm đó thông qua các job,” Dyadichkin nói. "Mặc dù có rất nhiều mô-đun chúng ta cần kết xuất, bản thân các tòa nhà chưa bao giờ thực sự là nút thắt cổ chai về hiệu suất kết xuất thuần túy."

Những công việc đó chạy trên Hệ thống Công việc C#, và đội ngũ biên dịch chúng bằng trình biên dịch Burst. Dyadichkin nói rằng chúng gần như luôn đi đôi với nhau trong mã khách hàng SEED’.

Giữ nguyên đường dẫn mặc định trong URP

SEED sử dụng URP để mở rộng trên PC và di động, và Klang Games cố tình bám sát các giá trị mặc định của Unity.

"Chúng tôi cố gắng tuân theo các giải pháp mặc định từ Unity, để chúng tôi luôn chắc chắn rằng bất cứ khi nào bản cập nhật tiếp theo đến, nó sẽ được bao gồm," Dyadichkin nói.

Điều đó quan trọng vì đội ngũ nâng cấp Unity khoảng một hoặc hai lần một năm – SEED hiện đang chạy trên Unity 6.3 – tiếp nhận các tính năng kết xuất mới khi dự án phát triển. Nơi trò chơi cần thứ gì đó tùy chỉnh, đội ngũ mở rộng URP thay vì thay thế nó, sử dụng các tính năng trình kết xuất tùy chỉnh cho các hiệu ứng và tương tác cụ thể của trò chơi.

Việc họ sử dụng Shader Graph tuân theo nguyên tắc tương tự. Các tài sản tự nhiên sử dụng shader mặc định Lit shader, trong khi các nhân vật và đối tượng sử dụng shader Unlit với một lần truyền ánh sáng tùy chỉnh. Dù thế nào đi nữa, đội không cần lo lắng về việc làm hỏng các tính năng hiệu suất của URP.

"Bạn có thể chắc chắn rằng nếu bạn tạo một Shader Graph, nó sẽ không làm hỏng việc gom nhóm SRP [Scriptable Render Pipeline], và nó sẽ không làm hỏng GPU Resident Drawer," Dyadichkin nói. "Việc chắc chắn rằng tất cả các tính năng cốt lõi của URP vẫn được hỗ trợ, trong khi bạn vẫn có không gian để tùy chỉnh bất cứ điều gì bạn muốn trong shader, là rất mạnh mẽ."

Lưới an toàn đó rất quan trọng trong một thế giới mà người chơi, chứ không phải nhà thiết kế, quyết định khách hàng phải vẽ bao nhiêu.

Tương tác với hàng nghìn đối tượng

Những người chơi dày đặc xây dựng, thì càng khó để dựng nên một xã hội – và để họ nhấp vào bất kỳ phần nào của nó.

Khi người chơi được phóng to, SEED sử dụng việc chọn điểm hoàn hảo theo pixel. Một tính năng trình kết xuất tùy chỉnh vẽ các đối tượng vào một mục tiêu kết xuất riêng biệt, một kết cấu ngoài màn hình mà GPU kết xuất vào thay vì màn hình. Mỗi đối tượng được mã hóa bằng một ID duy nhất mà cả CPU và GPU đều có thể đọc. Khách hàng đọc pixel dưới con trỏ để tìm chính xác đối tượng mà người chơi đang di chuột qua.

Trên thiết bị di động, đầu ngón tay kém chính xác hơn con trỏ, vì vậy máy khách cũng kiểm tra các pixel xung quanh mỗi lần chạm. Nếu nó phát hiện nhiều hơn một vật thể ở gần, nó sẽ hiển thị cho người chơi một danh sách để lựa chọn, giúp việc chọn các vật thể nhỏ hơn dễ dàng hơn ở những khu vực xây dựng dày đặc.

Khi người chơi thu nhỏ lại, máy khách chuyển về các tia vật lý, vì việc chọn bằng GPU khó mở rộng trên một góc nhìn rộng.

Đằng sau những tia quét đó là một số lượng lớn các bộ va chạm. SEED sử dụng Unity Physics không phải để mô phỏng, mà để khởi tạo chúng nhanh chóng và truy vấn chúng.

"Mọi cái cây đều có một bộ va chạm, mọi vật thể và có khả năng mọi viên gạch xây dựng đều có, và các nhân vật cũng như cây con cũng có," Dyadichkin nói. "Chúng ta có thể khởi tạo số lượng lớn các bộ va chạm này rất nhanh và sau đó thực hiện các truy vấn trên chúng để kiểm tra vị trí và các tương tác khác."

Khi một người chơi mở một tòa nhà, nội thất của nó sẽ hiện ra, và máy khách có nhiều thứ hơn để theo dõi khi họ di chuyển giữa các tầng và kiểm tra từng phòng riêng lẻ. Một công việc chạy liên tục xác định xem mỗi đối tượng có ở bên trong hay bên ngoài tòa nhà và nó chiếm phòng và tầng nào.

"Điều đó cho phép chúng tôi thực hiện đủ loại việc – vô hiệu hóa hoặc kích hoạt GameObjects, hoặc đặt các lớp kết xuất chính xác để kiểm soát tình hình chiếu sáng," Dyadichkin giải thích.

Hồ sơ các cầu thủ thế giới thực sự đã xây dựng

Phần khó nhất của việc tối ưu hóa cho các thế giới do người chơi xây dựng là có được dữ liệu thực tế. Klang Games lấy nó từ trò chơi trực tiếp.

Đội ngũ giữ các bản chụp máy chủ để phục hồi sau thảm họa, và khi người chơi xây dựng các xã hội đủ lớn, những bản chụp đó trở thành các trường hợp kiểm thử.

"Chúng ta có thể khôi phục những gì người chơi thực sự đã xây dựng và sử dụng nó để kiểm tra hiệu suất và kiểm tra các tính năng ở quy mô lớn," Fetisov nói. "Chúng ta có thể làm việc với các xã hội đã được xây dựng sẵn này thay vì bắt đầu từ đầu hoặc cố gắng tự mô phỏng dữ liệu."

Tải một ảnh chụp nhanh của một thành phố lớn được hiển thị cục bộ đã làm lộ ra một nút cổ chai kết xuất CPU không mong muốn trên PC.

"Trò chơi của chúng tôi không bị nghẽn cổ chai GPU phần lớn thời gian, mà là bị nghẽn cổ chai CPU," Dyadichkin nói. "Đó là một trò chơi được cách điệu hóa rất nhiều, low-poly với gần như không có kết cấu."

Sử dụng Unity Profiler, Dyadichkin phát hiện ra luồng render dành nhiều thời gian hơn dự kiến để gửi các lệnh vẽ. Đội sử dụng GPU Resident Drawer, vì vậy Dyadichkin mong đợi nó sẽ tạo các đối tượng đó. Frame Debugger cho thấy điều ngược lại.

"Chúng tôi vẫn mặc định sử dụng gộp SRP thay vì gộp lai," Dyadichkin cho biết. "Hóa ra GPU Resident Drawer không thu thập tất cả các đối tượng này vì hầu hết các Prefab của chúng tôi đều có Nhóm LOD."

Sự khác biệt có ý nghĩa ở quy mô của SEED. SRP Batcher giảm chi phí CPU khi thiết lập mỗi lệnh vẽ, nhưng vẫn gửi một lệnh cho mỗi đối tượng. GPU Resident Drawer đi xa hơn, nhóm các đối tượng có chung lưới và vật liệu thành các lần vẽ được nhân bản (instanced draws), mà Frame Debugger dán nhãn là các lô lai (hybrid batches). Với hàng ngàn đối tượng nhỏ, đó là sự khác biệt giữa nhiều lệnh gọi vẽ nhẹ và một vài lệnh gọi vẽ lớn.

Thủ phạm đằng sau các đối tượng bị bỏ lỡ là quá trình chuyển đổi LOD hoạt hình. Hiệu ứng trông tốt hơn, nhưng nó vẫn giữ các đối tượng tránh xa đường dẫn Ngăn kéo Cư trú GPU.

Chúng tôi đã vô hiệu hóa phần hoạt ảnh. "Chúng tôi vẫn có chuyển cảnh mờ dần, nhưng giờ là với các chuyển đổi được thiết lập thủ công," anh ấy nói. "Bây giờ các lệnh gọi vẽ được nhân bản lại, điều này đã giảm tải cho luồng kết xuất CPU của chúng tôi."

Vẽ nên một xã hội trưởng thành trong bộ nhớ di động

Trên di động, việc hiển thị của SEED đã gặp một ràng buộc khác. "Về phía di động, chúng tôi không bị giới hạn bởi CPU – chúng tôi bị giới hạn bởi bộ nhớ," Fetisov nói. Đó là vấn đề chính của dự án chúng ta.

Một xã hội trưởng thành có thể chứa số lượng lớn các tòa nhà, vật thể ngoài trời, nhân vật và lưới. Mọi lưới và vật liệu mà khách hàng dựng hình đều phải nằm trong bộ nhớ trước. Klang Games phụ thuộc nhiều vào Memory Profiler và so sánh ảnh chụp bộ nhớ để theo dõi xem bộ nhớ đó đi về đâu. Nhóm đã tìm thấy các texture được lưu trữ ba lần do một tham chiếu bị hỏng, các phụ thuộc Addressables trùng lặp cùng một vật liệu và các bộ sưu tập C# lớn hơn nhiều so với mức cần thiết.

"Rất nhiều vấn đề phát sinh ở chỗ, trên máy tính để bàn thì ổn và mọi người không thực sự để ý, nhưng trên di động thì đó là một vấn đề lớn," Fetisov nói. "Chúng tôi đã dựa rất nhiều vào Unity Memory Profiler, đặc biệt là các bản khác biệt ảnh chụp [bộ nhớ]."

Ngay cả khi không có kết cấu, hình học vẫn tạo nên giá trị.

"Một số lưới khá thô, đặc biệt là cây cối," Fetisov nói. "Nếu bạn tải tất cả các LOD, một cây đơn lẻ có thể chiếm hàng megabyte bộ nhớ, và chúng ta có nhiều biến thể cây."

Vì đội builds Addressables per platform, nó có thể gửi các cây đơn giản hóa đến thiết bị di động mà không cần thay đổi bất kỳ mã trò chơi nào. “Cùng một mã tải chiếc ghế trên máy tính để bàn cũng tải chiếc ghế trên thiết bị di động,” Fetisov giải thích. "Nhưng bản thân các Addressables có thể là các tài sản được tối ưu hóa cho di động."

Sự thay đổi lớn hơn là thay thế hoàn toàn các Nhóm LOD trên thiết bị di động. Các LOD cổ điển có nghĩa là lưu trữ nhiều lưới cho mỗi loại đối tượng trong bộ nhớ – cùng chi phí mà Fetisov mô tả với cây. Mesh LOD, được giới thiệu trong Unity 6.2, thay vì lưu trữ từng mức chi tiết bên trong một lưới duy nhất, và các biến thể di động của SEED hiện sử dụng nó độc quyền. Nó cũng giảm bớt khối lượng công việc cho đội ngũ nghệ thuật nhỏ của Klang Games.

"Việc chuyển từ LOD sang Mesh LOD là một bước quan trọng để có thể hiển thị thế giới trò chơi trên các thiết bị di động," Fetisov cho biết.

Thiết kế cho những gì người chơi sẽ xây dựng tiếp theo

Thách thức kết xuất cốt lõi của SEED sẽ không biến mất: Người chơi quyết định những gì máy khách phải vẽ, và họ không bao giờ ngừng xây dựng. "Đó là sự cân bằng liên tục giữa độ trung thực hình ảnh mà chúng tôi hình dung cho các thế giới do người chơi tạo và tốc độ khung hình ổn định trên các thiết bị cấu hình thấp," Dyadichkin cho biết.

Klang Games không thể dự đoán những gì người chơi sẽ xây dựng tiếp theo – nhưng nó có thể kiểm tra dựa trên những gì họ đã xây dựng.

"Thiết kế, xây dựng và thử nghiệm cho quy mô mục tiêu của bạn ngay từ ngày đầu tiên," Fetisov nói. "Hãy thử nghiệm với các tải trọng thực tế sớm và tiếp tục làm điều đó."

SEED có sẵn trong bản truy cập sớm. Hãy xem thêm các câu chuyện từ các nhà phát triển Unity trên Unity Blog và Resource Hub.