Model Otoritas Server

Dalam model otoritas server, server adalah satu-satunya sumber kebenaran untuk keseluruhan keadaan permainan, dan klien hanya dipercaya untuk melaporkan masukan mereka sendiri. Arsitektur ini adalah fondasi netcode inti dari permainan yang adil dan kompetitif karena mencegah kelas kecurangan seperti flyhacks atau speedhacks dengan tidak pernah mempercayai klien untuk melaporkan posisi atau keadaan mereka sendiri.

Keuntungan

Dalam sistem yang dimiliki server secara naif, klien hanya akan mengirimkan masukan mereka ke server dan menampilkan hasil permainan yang dikirimkan kembali oleh server. Meskipun secara teknis benar, sistem seperti itu akan menghadapi latensi masukan yang signifikan karena setiap tindakan pemain harus melakukan perjalanan ke server, diproses, dan hasilnya dikirim kembali ke klien sebelum dapat ditampilkan. Untuk kebanyakan permainan, terutama yang cepat, keterlambatan perjalanan ini akan membuat gameplay terasa lambat, tidak responsif, dan tidak dapat dimainkan.

Dalam model otoritas server Roblox, latensi diimbangi dengan membuat klien segera memprediksi efek dari masukan mereka selain mengirimkannya ke server. Misalnya, ketika seorang pemain menekan sebuah tombol, klien tidak menunggu server untuk merespons; sebaliknya, ia memprediksi beberapa frame ke depan dari keadaan server yang diketahui terakhir. Ini memungkinkan klien untuk menunjukkan hasil dari tindakan masukan secara instan, secara efektif menyembunyikan latensi jaringan dan membuat permainan terasa responsif.

Kadang-kadang klien akan salah memprediksi (misprediction) dan, karena latensi jaringan, klien tidak akan mengetahui bahwa ia telah membuat kesalahan selama beberapa frame. Misalnya:

Ketika sebuah kesalahan prediksi terdeteksi, klien harus memperbaiki prediksinya berdasarkan keadaan otoritatif server. Jika keadaan otoritatif berbeda dari keadaan yang diprediksi klien, klien harus mengembalikan dan mensimulasikan ulang frame yang diprediksinya. Sistem prediksi sisi klien, pengembalian, dan simulasi ulang ini dikenal sebagai "kompensasi latensi" dan membantu membuat permainan multipemain yang otoritatif server terasa halus dan responsif.

Pengaturan

Karena model otoritas server memerlukan teknologi mesin lain agar berfungsi dengan benar, Anda pertama-tama harus mengatur properti berikut pada objek Workspace di Explorer:

1. Workspace.NextGenerationReplication harus diaktifkan
2. Workspace.PlayerScriptsUseInputActionSystem harus diaktifkan
3. Workspace.SignalBehavior harus Deferred
4. Workspace.UseFixedSimulation harus diaktifkan
5. Workspace.StreamingEnabled harus diaktifkan
6. Workspace.AuthorityMode harus Server (semua di atas harus diatur terlebih dahulu)

Konsep

Sistem otoritas server berjalan berdasarkan beberapa konsep inti sebagai berikut.

Prediksi Klien

Melalui prediksi klien, klien mensimulasikan beberapa frame ke depan dari keadaan server yang diketahui terakhir untuk memprediksi efek dari masukan pemain segera. Ini menyembunyikan latensi masukan, tetapi prediksi tersebut mungkin kemudian terbukti salah (misprediction klien) dan oleh karena itu memerlukan koreksi. Klien berusaha untuk mensimulasikan cukup jauh ke depan dari keadaan server otoritatif terakhir yang diketahui sehingga masukan mereka tiba di server pada frame yang dimaksud. Jumlah frame yang akan diprediksi oleh klien di depan keadaan server yang diketahui didasarkan pada latensi antara klien dan server.

Misprediksi Klien

Ketika klien menerima keadaan otoritatif dari server, ia memeriksa keadaan tersebut terhadap catatan historis dari apa yang diprediksinya secara lokal untuk frame tersebut. Ketika ada perbedaan antara apa yang diprediksi klien dan apa yang sebenarnya dilakukan server, ini adalah sebuah misprediksi. Misprediksi dapat terjadi karena beberapa alasan, termasuk perubahan latensi jaringan, pemain lain bertindak dengan cara yang tidak diperkirakan klien, permainan menjalankan logika tertentu secara eksklusif di server, dan lain-lain.

Jika keadaan otoritatif berbeda dari keadaan yang diprediksi klien, klien harus mengembalikan dan mensimulasikan ulang.

Pengembalian dan Simulasi Ulang

Ketika klien mendeteksi sebuah misprediksi, ia harus mengatur ulang ke keadaan otoritatif server dan kemudian mensimulasikan ulang untuk melompat kembali ke frame yang diprediksinya. Berdasarkan latensi jaringan, klien berusaha untuk mensimulasikan cukup jauh ke depan dari keadaan otoritatif server yang terakhir diketahui sehingga masukan mereka tiba di server pada frame yang dimaksud.

Sebagai ringkasan, klien:

1. Menerima keadaan otoritatif dari server dan membandingkannya dengan keadaan yang diprediksinya sendiri.
2. Jika prediksi klien salah:

   1. Klien mengembalikan ke keadaan otoritatif terakhir yang diterima dari server.
   2. Klien mensimulasikan ulang dari keadaan otoritatif ke keadaan yang diprediksinya, menerapkan kembali masukan lokal apa pun.

Implementasi

Kepemilikan jaringan dan prediksi

Dalam model otoritas server, Anda dapat menjaga objek gameplay inti tetap dimiliki server tanpa menanggung biaya latensi masukan yang biasanya terkait dengan kepemilikan server. Hal-hal seperti mobil, karakter pemain, atau objek kritis lainnya dalam gameplay dapat tetap dimiliki server, bahkan saat berinteraksi dengan pemain lain.

Secara default, Roblox akan secara otomatis memprediksi properti dengan akses simulasi dekat pemain lokal Character, tetapi jika Anda ingin kontrol yang lebih terperinci, Anda dapat secara eksplisit memaksa prediksi instance dihidupkan atau dimatikan dengan RunService:SetPredictionMode().

Sinkronisasi simulasi

Dalam model otoritas server, klien dan server harus menjalankan simulasi inti, dan simulasi klien harus dapat mengembalikan dan mensimulasikan ulang ketika terjadi misprediksi. Untuk mengaktifkan ini, tulis logika inti Anda di dalam fungsi yang terikat melalui RunService:BindToSimulation() dalam ModuleScript yang diinisialisasi di klien dan server.

Selama simulasi ulang, Roblox akan menjalankan kembali fungsi yang terikat ke simulasi melalui BindToSimulation(). Memproses masukan pemain, berinteraksi dengan objek fisika yang disinkronisasi, dan memperbarui keadaan permainan inti harus dilakukan di dalam fungsi-fungsi yang terikat tersebut.

ModuleScript bernama Simulation di ReplicatedStorage:

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

local Simulation = {}

Simulation.Initialize = function()
	RunService:BindToSimulation(function(deltaTime)
		-- Membaca masukan pemain
		-- Memperbarui keadaan permainan
	end)
end

return Simulation

Sinkronisasi keadaan dengan atribut

Roblox secara otomatis menyinkronkan semua properti dengan akses simulasi pada instance yang diprediksi. Untuk data kustom, atribut adalah cara utama untuk menyinkronkan instance yang ditandai sebagai diprediksi; pada instance tersebut, setiap ketidakcocokan dalam nilai atribut antara sumber kebenaran server dan prediksi klien akan memicu pengembalian dan simulasi ulang.

Batasan atribut

Agar dapat direplikasi, sebuah atribut harus memenuhi semua kriteria berikut:

• Itu adalah salah satu dari 64 atribut pertama pada Instance nya.
• Nama atribut tidak boleh lebih dari 50 karakter.
• Jika atribut tipe string, nilainya tidak boleh lebih dari 50 karakter.

Akses simulasi

Banyak properti dan metode dalam referensi API mesin mencakup label Akses Simulasi, misalnya BasePart.CFrame. Properti dengan label ini akan diprediksi oleh sistem otoritas server. Selain itu, hanya properti dan metode dengan label ini yang dapat diakses di dalam fungsi yang terikat dengan RunService:BindToSimulation().

Tindakan masukan

Dalam permainan yang otoritatif server, cara utama bagi klien untuk mempengaruhi keadaan permainan adalah melalui Sistem Tindakan Masukan. Masukan ini dikirim ke server dan diputar ulang selama simulasi ulang di klien. Oleh karena itu, InputActions harus digunakan untuk semua masukan yang mempengaruhi simulasi inti dan harus diperiksa untuk kepatuhan sebelum mereka diproses.

Perhatikan bahwa InputContexts harus merupakan keturunan dari Player sehingga mesin tahu siapa yang memiliki InputContext. Salah satu pendekatan adalah menambahkan InputContexts Anda ke folder di bawah ReplicatedStorage dan menggunakan Script di bawah ServerScriptService untuk mengkloning InputContexts per pemain:

InputSetup
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

Dengan pola ini, Anda dapat membaca InputActions untuk semua pemain di RunService:BindToSimulation() di klien dan server untuk menerima data yang sama untuk frame tertentu dan mencatat masukan frame sebelumnya dalam sebuah atribut, misalnya untuk memicu lari karakter ketika tindakan masukan RunAction diaktifkan.

Perhatikan bahwa jika Anda perlu menulis data kustom ke Sistem Tindakan Masukan, Anda harus menggunakan fungsi yang terhubung ke RunService.RenderStepped atau RunService:BindToRenderStep(), bukan RunService:BindToSimulation(). Memicu InputAction dalam BindToSimulation() dapat menyebabkan klien menghasilkan hasil yang salah selama simulasi ulang.

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

RunService:BindToRenderStep("CameraInput", Enum.RenderPriority.Last.Value, function()
	-- Mengirim vektor maju kamera klien ke server melalui InputAction
	local cameraForwardInputAction = Players.LocalPlayer.PlayContext.CameraForward
	local cameraForwardVector = Workspace.CurrentCamera.CFrame.LookVector
	cameraForwardInputAction:Fire(cameraForwardVector)
end)

Acara jarak jauh

Acara jarak jauh masih dapat digunakan dalam model otoritas server untuk memfasilitasi komunikasi diskrit antara klien dan server. Misalnya, server dapat menggunakan acara jarak jauh untuk menyiarkan data tentang pemain yang mencetak gol atau mengambil objek, dan klien dapat menggunakan acara jarak jauh sebagai API alternatif untuk mengirim masukan ke server, seperti untuk menekan tombol atau mengetuk objek di dunia 3D.

Animasi, suara, dan efek

Efek sisi klien seperti animasi dan suara harus ditulis dengan mengetahui bahwa simulasi klien hanyalah prediksi dari keadaan server otoritatif. BindToSimulation() membatasi properti dan metode yang dapat dipanggil dari dalam fungsi yang terikat untuk membantu Anda dalam menulis hanya ke keadaan simulasi yang disinkronkan. Menampilkan hasil dari simulasi ini, memicu efek dan suara, dll. harus dilakukan dalam fungsi terpisah yang terhubung ke RenderStepped yang membaca hasil dari simulasi dan memicu efek yang diinginkan.

Panduan lebih lanjut tentang merender simulasi yang diprediksi dibahas dalam panduan teknik-teknik lanjutan.

Proyek contoh

Selain dokumentasi ini, template berikut dapat membantu Anda memulai: