Mô hình quyền lực máy chủ

Trong một mô hình quyền lực máy chủ, máy chủ là nguồn thông tin duy nhất cho toàn bộ trạng thái trò chơi, và khách hàng chỉ được tin tưởng để báo cáo các đầu vào của riêng họ. Kiến trúc này là nền tảng mã mạng cốt lõi của một trò chơi công bằng, cạnh tranh, vì nó ngăn chặn các hình thức gian lận như flyhacks hoặc speedhacks bằng cách không bao giờ tin tưởng một khách hàng để báo cáo vị trí hoặc trạng thái của chính nó.

Lợi ích

Trong một hệ thống thuộc về máy chủ đơn giản, các khách hàng chỉ gửi đầu vào của họ tới máy chủ và hiển thị kết quả của trò chơi được gửi lại bởi máy chủ. Mặc dù về mặt kỹ thuật là chính xác, một hệ thống như vậy sẽ gặp phải độ trễ đầu vào đáng kể vì mỗi hành động của người chơi phải di chuyển đến máy chủ, được xử lý và phải có kết quả được gửi lại cho khách hàng trước khi nó có thể được hiển thị. Đối với hầu hết các trò chơi, đặc biệt là những trò chơi nhanh, độ trễ quay vòng đó sẽ làm cho gameplay cảm thấy lag, không phản hồi và không thể chơi được.

Trong mô hình quyền lực máy chủ của Roblox, độ trễ được bù đắp bằng cách cho phép khách hàng ngay lập tức dự đoán các hiệu ứng của đầu vào của họ ngoài việc gửi chúng tới máy chủ. Ví dụ, khi một người chơi nhấn phím, khách hàng không chờ đợi phản hồi từ máy chủ; thay vào đó, nó dự đoán vài khung hình trước trạng thái máy chủ đã biết cuối cùng. Điều này cho phép khách hàng hiển thị kết quả của hành động đầu vào ngay lập tức, ẩn đi độ trễ mạng và làm cho trò chơi cảm thấy phản hồi.

Đôi khi khách hàng sẽ dự đoán sai (dự đoán sai) và, do độ trễ mạng, khách hàng sẽ không biết rằng nó đã mắc sai lầm trong vài khung hình. Ví dụ:

Khi một sai sót được phát hiện, khách hàng phải sửa chữa dự đoán của mình dựa trên trạng thái có thẩm quyền của máy chủ. Nếu trạng thái có thẩm quyền khác với trạng thái dự đoán của khách hàng, khách hàng phải quay lại và tái mô phỏng các khung hình dự đoán của nó. Hệ thống dự đoán phía khách hàng, quay lại và tái mô phỏng này được gọi là "bù đắp độ trễ" và giúp các trò chơi nhiều người chơi có quyền lực máy chủ cảm thấy mượt mà và phản hồi.

Thiết lập

Mô hình quyền lực máy chủ yêu cầu một số công nghệ động cơ khác để hoạt động đúng cách. Xác nhận các cài đặt thuộc tính sau trên đối tượng Workspace trong Explorer:

1. Workspace.AuthorityMode phải là Server (cài đặt này tự động thiết lập năm cài đặt tiếp theo).
2. Workspace.NextGenerationReplication phải được kích hoạt.
3. Workspace.PlayerScriptsUseInputActionSystem phải được kích hoạt.
4. Workspace.SignalBehavior phải là Deferred.
5. Workspace.UseFixedSimulation phải được kích hoạt.
6. Workspace.StreamingEnabled phải được kích hoạt.

Khái niệm

Hệ thống quyền lực máy chủ hoạt động dựa trên một vài khái niệm cốt lõi như sau.

Dự đoán phía khách hàng

Thông qua dự đoán phía khách hàng, khách hàng mô phỏng một vài khung hình trước trạng thái máy chủ đã biết cuối cùng để dự đoán các hiệu ứng của đầu vào người chơi ngay lập tức. Điều này ẩn đi độ trễ đầu vào, nhưng dự đoán có thể sau đó trở nên không chính xác (dự đoán sai phía khách hàng) và do đó cần phải sửa chữa. Khách hàng cố gắng mô phỏng vừa đủ xa phía trước để trạng thái máy chủ có thẩm quyền cuối cùng của nó mà các đầu vào của nó đến máy chủ ở khung hình dự kiến. Số lượng khung hình mà khách hàng sẽ dự đoán phía trước trạng thái máy chủ đã biết phụ thuộc vào độ trễ giữa khách hàng và máy chủ.

Dự đoán sai phía khách hàng

Khi khách hàng nhận được trạng thái có thẩm quyền từ máy chủ, nó kiểm tra trạng thái đó với một hồ sơ lịch sử về những gì nó đã dự đoán cục bộ cho khung hình đó. Khi có sự khác biệt giữa những gì khách hàng dự đoán và những gì máy chủ thực tế đã làm, đây là một dự đoán sai. Các dự đoán sai có thể xảy ra vì một số lý do, bao gồm sự thay đổi trong độ trễ mạng, những người chơi khác hành động theo cách mà khách hàng không dự đoán được, trò chơi chạy một số logic độc quyền trên máy chủ, v.v.

Nếu trạng thái có thẩm quyền khác với trạng thái dự đoán của khách hàng, khách hàng phải quay lại và tái mô phỏng.

Quay lại và tái mô phỏng

Khi một khách hàng phát hiện một dự đoán sai, nó phải đặt lại về trạng thái có thẩm quyền của máy chủ và sau đó tái mô phỏng để nhảy trở lại khung hình dự đoán của nó. Dựa trên độ trễ mạng, khách hàng cố gắng mô phỏng vừa đủ xa phía trước để trạng thái máy chủ có thẩm quyền cuối cùng của nó mà các đầu vào của nó đến máy chủ ở khung hình dự kiến.

Tóm lại, khách hàng:

1. Nhận trạng thái có thẩm quyền từ máy chủ và so sánh nó với trạng thái dự đoán của chính nó.
2. Nếu dự đoán của khách hàng là không chính xác:

   1. Khách hàng quay lại trạng thái có thẩm quyền cuối cùng nhận được từ máy chủ.
   2. Khách hàng tái mô phỏng từ trạng thái có thẩm quyền đến trạng thái dự đoán của nó, áp dụng lại bất kỳ đầu vào cục bộ nào.

Triển khai

Quyền sở hữu mạng và dự đoán

Trong mô hình quyền lực máy chủ, bạn có thể giữ cho các đối tượng gameplay cốt lõi thuộc về máy chủ mà không phát sinh chi phí độ trễ đầu vào thường thấy liên quan đến quyền sở hữu máy chủ. Những thứ như ô tô, nhân vật người chơi, hoặc các đối tượng quan trọng khác của gameplay vẫn có thể thuộc về máy chủ, ngay cả khi tương tác với các người chơi khác.

Mặc định, Roblox sẽ tự động dự đoán các thuộc tính với quyền truy cập mô phỏng gần nhân vật người chơi cục bộ Character, nhưng nếu bạn muốn kiểm soát chi tiết hơn, bạn có thể buộc rõ ràng chế độ dự đoán của một instance bằng RunService:SetPredictionMode().

Đồng bộ hóa mô phỏng

Trong mô hình quyền lực máy chủ, cả khách hàng và máy chủ đều phải chạy mô phỏng cốt lõi, và mô phỏng của khách hàng cần phải có khả năng quay lại và tái mô phỏng khi một dự đoán sai occurs. Để bật điều này, hãy viết logic cốt lõi của bạn bên trong các hàm được ràng buộc thông qua RunService:BindToSimulation() trong một ModuleScript được khởi tạo trên cả khách hàng và máy chủ.

Trong một lần tái mô phỏng, Roblox sẽ chạy lại các hàm được ràng buộc cho mô phỏng thông qua BindToSimulation(). Xử lý đầu vào của người chơi, tương tác với các đối tượng vật lý đồng bộ, và cập nhật trạng thái trò chơi cốt lõi nên nằm bên trong các hàm đã được ràng buộc đó.

ModuleScript có tên là Simulation trong ReplicatedStorage:

local RunService = game:GetService("RunService")
local Players = game:GetService("Players")

local Simulation = {}

Simulation.Initialize = function()
	RunService:BindToSimulation(function(deltaTime)
		-- Đọc đầu vào của người chơi
		-- Cập nhật trạng thái trò chơi
	end)
end

return Simulation

Đồng bộ trạng thái với thuộc tính

Roblox tự động đồng bộ hóa tất cả các thuộc tính với quyền truy cập mô phỏng trên các instance được dự đoán. Đối với dữ liệu tùy chỉnh, thuộc tính là cách chính để đồng bộ hóa các instance được đánh dấu là dự đoán; trên các instance như vậy, bất kỳ sự không khớp nào trong giá trị thuộc tính giữa nguồn thông tin có thẩm quyền của máy chủ và dự đoán của khách hàng sẽ kích hoạt một quay lại và tái mô phỏng hoàn toàn.

Giới hạn thuộc tính

Để được nhân bản, một thuộc tính phải đáp ứng tất cả các tiêu chí sau:

• Nó nằm trong số 64 thuộc tính đầu tiên trên Instance của nó.
• Tên của nó có tối đa 50 ký tự.
• Nếu là thuộc tính kiểu chuỗi, giá trị của nó có tối đa 50 ký tự.

Quyền truy cập mô phỏng

Nhiều thuộc tính và phương thức trong tài liệu API của động cơ có nhãn Quyền truy cập mô phỏng, ví dụ, BasePart.CFrame. Các thuộc tính có nhãn này sẽ được dự đoán bởi hệ thống quyền lực máy chủ. Ngoài ra, chỉ các thuộc tính và phương thức có nhãn này mới có thể được truy cập bên trong các hàm được ràng buộc với RunService:BindToSimulation().

Hành động đầu vào

Trong một trò chơi có quyền lực máy chủ, cách chính để khách hàng ảnh hưởng đến trạng thái trò chơi là thông qua Hệ thống Hành động Đầu vào. Các đầu vào này được gửi tới máy chủ và được phát lại trong khi tái mô phỏng trên khách hàng. Kết quả là, InputActions nên được sử dụng cho tất cả các đầu vào ảnh hưởng đến mô phỏng cốt lõi và chúng nên được kiểm tra tính hợp lệ trước khi được xử lý.

Lưu ý rằng InputContexts phải là hậu duệ của một Player để động cơ biết ai có quyền sở hữu InputContext. Một cách tiếp cận là thêm InputContexts của bạn vào một thư mục dưới ReplicatedStorage và sử dụng một Script dưới ServerScriptService để sao chép InputContexts theo từng người chơi:

local Players = game:GetService("Players")
local ReplicatedStorage = game:GetService("ReplicatedStorage")

local InputsFolder = ReplicatedStorage:WaitForChild("Inputs")

local function onPlayerAdded(player)
	local clone = InputsFolder:Clone()
	clone.Parent = player
end

Players.PlayerAdded:Connect(onPlayerAdded)

for _, player in Players:GetPlayers() do
	onPlayerAdded(player)
end

Sử dụng mẫu hình này, bạn có thể đọc InputActions cho tất cả người chơi trong RunService:BindToSimulation() trên cả khách hàng và máy chủ để nhận cùng một dữ liệu cho một khung hình đã cho và ghi lại đầu vào của khung hình trước trong một thuộc tính, ví dụ để kích hoạt một hành động chạy của nhân vật khi một hành động đầu vào RunAction được kích hoạt.

Sự kiện từ xa

Các sự kiện từ xa vẫn có thể được sử dụng trong mô hình quyền lực máy chủ để tạo điều kiện cho giao tiếp riêng biệt giữa khách hàng và máy chủ. Ví dụ, máy chủ có thể sử dụng sự kiện từ xa để phát thông tin về những người chơi ghi điểm hoặc nhặt đồ vật, và khách hàng có thể sử dụng sự kiện từ xa như một API thay thế để gửi đầu vào tới máy chủ, chẳng hạn như cho các lần nhấn nút hoặc chạm các đối tượng trong thế giới 3D.

Hoạt hình, âm thanh và hiệu ứng

Các hiệu ứng phía khách hàng như hoạt hình và âm thanh phải được viết với ý thức rằng mô phỏng khách hàng chỉ là một dự đoán của trạng thái có thẩm quyền của máy chủ. BindToSimulation() hạn chế những thuộc tính và phương thức nào có thể được gọi từ bên trong các hàm đã được ràng buộc để giúp hướng dẫn bạn chỉ viết vào trạng thái mô phỏng đồng bộ. Hiển thị kết quả của mô phỏng này, kích hoạt hiệu ứng và âm thanh, v.v. nên được thực hiện trong một hàm riêng biệt được kết nối với RenderStepped mà đọc kết quả của mô phỏng và kích hoạt các hiệu ứng mong muốn.

Hướng dẫn thêm về việc hiển thị một mô phỏng dự đoán được đề cập trong hướng dẫn các kỹ thuật nâng cao.

Dự án ví dụ

Ngoài tài liệu này, các mẫu sau có thể giúp bạn bắt đầu: