نموذج سلطة الخادم

في نموذج سلطة الخادم، يُعتبر الخادم هو المصدر الوحيد للحقيقة لحالة اللعبة بأكملها، ويُعتمد على العملاء فقط للإبلاغ عن مدخلاتهم الخاصة. هذه العمارة هي الأساس الرئيسي للشفرة الشبكية في لعبة تنافسية عادلة، لأنها تمنع حدوث أنواع معينة من الغش مثل استخدام تقنيات الطيران أو تسريع الحركة بعدم الوثوق بالعميل في الإبلاغ عن موضعه أو حالته الخاصة.

المزايا

في نظام مملوك للخادم بشكل ساذج، سيرسل العملاء ببساطة مدخلاتهم إلى الخادم ويعرضون نتائج اللعبة المرسلة من قِبل الخادم. على الرغم من أنها صحيحة من الناحية التقنية، إلا أن مثل هذا النظام سيتعرض لزمن تأخير في المدخلات كبير لأن كل إجراء من اللاعب يجب أن ينتقل إلى الخادم، يُعالج، ثم تُرسل النتيجة إلى العميل قبل أن يمكن عرضها. بالنسبة لمعظم الألعاب، وخاصةً تلك السريعة الوتيرة، من شأن تأخير جولة الذهاب والإياب أن يجعل طريقة اللعب تبدو غير سريعة الاستجابة وغير قابلة للعب.

في نموذج سلطة الخادم الخاص بـ Roblox، يتم تعويض زمن التأخير من خلال جعل العملاء يتوقعون على الفور تأثيرات مدخلاتهم بالإضافة إلى إرسالها إلى الخادم. على سبيل المثال، عندما يضغط اللاعب على زر، لا ينتظر العميل رد الخادم؛ بدلاً من ذلك يتوقع بضع إطارات إلى الأمام من آخر حالة معروفة للخادم. هذا يسمح للعميل بعرض نتيجة إجراء المدخلات على الفور، مما يخفي زمن التأخير الشبكي ويجعل اللعبة تبدو سريعة الاستجابة.

أحيانًا ستخطئ توقعات العميل (خطأ في التوقع)، وبسبب زمن التأخير الشبكي، لن يعرف العميل أنه ارتكب خطأ لبضع إطارات. على سبيل المثال:

عندما يتم اكتشاف خطأ في التوقع، يجب على العميل تصحيح توقعه بناءً على الحالة الموثوقة للخادم. إذا كانت الحالة الموثوقة مختلفة عن الحالة المتوقعة للعميل، يجب على العميل العودة إلى الوراء وإعادة المحاكاة لإطاراته المتوقعة. تُعرف هذه النظام من توقع العميل، العودة إلى الوراء، وإعادة المحاكاة باسم "تعويض زمن التأخير" وتساعد على جعل الألعاب متعددة اللاعبين التي تعتمد على الخادم تشعر بالسلاسة والاستجابة.

الإعداد

نظرًا لأن نموذج سلطة الخادم يتطلب تقنيات أخرى في المحرك لتعمل بشكل صحيح، يجب عليك أولاً تعيين الخصائص التالية على كائن Workspace في المستكشف:

1. يجب تمكين Workspace.NextGenerationReplication
2. يجب تمكين Workspace.PlayerScriptsUseInputActionSystem
3. يجب أن يكون Workspace.SignalBehavior هو Deferred
4. يجب تمكين Workspace.UseFixedSimulation
5. يجب تمكين Workspace.StreamingEnabled
6. يجب أن يكون Workspace.AuthorityMode هو Server (يجب تعيين كل ما سبق أولاً)

المفاهيم

يعمل نظام سلطة الخادم على عدد من المفاهيم الأساسية كما يلي.

توقع العميل

من خلال توقع العميل، يقوم العميل بمحاكاة بضع إطارات إلى الأمام من آخر حالة معروفة للخادم لتوقع تأثيرات مدخلات اللاعب على الفور. هذا يخفي زمن تأخير المدخلات، لكن التوقع قد يتبين لاحقًا أنه غير صحيح (خطأ العميل في التوقع) وبالتالي يحتاج إلى تصحيح. يحاول العميل محاكاة بعيدًا بما فيه الكفاية عن آخر حالة موثوقة معروفة للخادم حتى تصل مدخلاته إلى الخادم في الإطار المقصود. عدد الإطارات التي سيتوقعها العميل إلى الأمام من حالة الخادم المعروفة يعتمد على زمن التأخير بين العميل والخادم.

خطأ العميل في التوقع

عندما يتلقى العميل الحالة الموثوقة من الخادم، يتحقق من تلك الحالة مقابل سجل تاريخي لما توقعه محليًا لتلك الإطار. عندما يكون هناك اختلاف بين ما توقعه العميل وما فعله الخادم فعليًا، فإن هذا يُعتبر خطأ في التوقع. يمكن أن تحدث أخطاء التوقع لعدة أسباب، بما في ذلك التغيرات في زمن تأخير الشبكة، تصرفات لاعبين آخرين بطرق لم يتوقعها العميل، تشغيل بعض المنطق في اللعبة حصريًا على الخادم، إلخ.

إذا كانت الحالة الموثوقة مختلفة عن الحالة المتوقعة للعميل، يجب على العميل العودة إلى الوراء وإعادة المحاكاة.

العودة إلى الوراء وإعادة المحاكاة

عندما يكتشف العميل خطأ في التوقع، يجب عليه إعادة ضبطه إلى الحالة الموثوقة للخادم ثم إعادة المحاكاة للعودة إلى إطاره المتوقع. بناءً على زمن التأخير في الشبكة، يحاول العميل محاكاة بعيدًا بما فيه الكفاية عن آخر حالة موثوقة معروفة للخادم حتى تصل مدخلاته إلى الخادم في الإطار المقصود.

باختصار، العميل:

1. يتلقى الحالة الموثوقة من الخادم ويقارنها مع حالة التوقع الخاصة به.
2. إذا كانت توقعات العميل غير صحيحة:

   1. يعود العميل إلى آخر حالة موثوقة معروفة تم تلقيها من الخادم.
   2. يعيد العميل المحاكاة من الحالة الموثوقة إلى حالته المتوقعة، مكررًا أي مدخلات محلية.

التنفيذ

ملكية الشبكة والتوقع

في نموذج سلطة الخادم، يمكنك المحافظة على كائنات اللعبة الأساسية المملوكة للخادم دون تحمل تكلفة زمن التأخير المرتبط عادةً بملكية الخادم. يمكن أن تبقى أشياء مثل السيارات، شخصيات اللاعبين، أو كائنات أخرى مهمة للعبة مملوكة للخادم، حتى عند التفاعل مع لاعبين آخرين.

بشكل افتراضي، سيقوم Roblox تلقائيًا بتوقع الخصائص ذات الوصول إلى المحاكاة بالقرب من اللاعب المحلي Character، ولكن إذا كنت ترغب في مزيد من التحكم الدقيق، يمكنك إجبار توقع كائن معين على العرض أو الإيقاف باستخدام RunService:SetPredictionMode().

مزامنة المحاكاة

في نموذج سلطة الخادم، يجب على العميل والخادم كليهما تشغيل المحاكاة الأساسية، ويجب أن تكون محاكاة العميل قادرة على العودة إلى الوراء وإعادة المحاكاة عندما يحدث خطأ في التوقع. لتمكين ذلك، اكتب المنطق الأساسي الخاص بك داخل دوال مرتبطة عبر RunService:BindToSimulation() في ModuleScript التي يتم تهيئتها على كل من العميل والخادم.

خلال عملية إعادة المحاكاة، سيقوم Roblox بإعادة تشغيل الدوال المرتبطة بالمحاكاة عبر BindToSimulation(). يجب أن تعيش عمليات معالجة مدخلات اللاعبين، والتفاعل مع الكائنات الفيزيائية المتزامنة، وتحديث حالة اللعبة الأساسية داخل تلك الدوال المرتبطة.

ModuleScript باسم Simulation في ReplicatedStorage:

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

local Simulation = {}

Simulation.Initialize = function()
	RunService:BindToSimulation(function(deltaTime)
		-- قراءة مدخلات اللاعبين
		-- تحديث حالة اللعبة
	end)
end

return Simulation

مزامنة الحالة مع الخصائص

يقوم Roblox تلقائيًا بمزامنة جميع الخصائص ذات الوصول إلى المحاكاة على الكائنات المتوقعة. بالنسبة للبيانات المخصصة، تُعتبر الخصائص هي الطريقة الأساسية لمزامنة الكائنات التي تم وضع علامة عليها كمستندة؛ على هذه الكائنات، ستحفز أي اختلاف في قيم الخصائص بين مصدر الحقيقة الخاص بالخادم وتوقع العميل بالكامل العودة إلى الوراء وإعادة المحاكاة.

قيود الخصائص

لكي يتم نسخ الخصائص، يجب أن تلبي الخاصية جميع المعايير التالية:

• يجب أن تكون من بين أول 64 خاصية على كائنها Instance.
• يجب أن يحتوي اسمها على 50 حرفًا كحد أقصى.
• إذا كانت خاصية من نوع نص، فيجب ألا تحتوي قيمتها على أكثر من 50 حرفًا.

الوصول إلى المحاكاة

تتضمن العديد من الخصائص والطرق في مرجع واجهة برمجة التطبيقات الخاصة بمحرك البرمجة علامة الوصول إلى المحاكاة، على سبيل المثال BasePart.CFrame. ستُتوقع الخصائص التي تحمل هذه العلامة بواسطة نظام سلطة الخادم. بالإضافة إلى ذلك، يمكن فقط الوصول إلى الخصائص والطرق التي تحمل هذه العلامة داخل الدوال المرتبطة بواسطة RunService:BindToSimulation().

إجراءات المدخلات

في لعبة تعتمد على الخادم، فإن الطريقة الأساسية لتمييز العميل لحالة اللعبة هي من خلال نظام إجراءات المدخلات. يتم إرسال هذه المدخلات إلى الخادم ويتم إعادة تشغيلها خلال إعادة المحاكاة على العميل. نتيجة لذلك، يجب استخدام InputActions لجميع المدخلات التي تؤثر على المحاكاة الأساسية ويجب التحقق منها من حيث الصلاحية قبل معالجتها.

لاحظ أن InputContexts يجب أن تكون من نسل Player حتى يعرف المحرك من يملك InputContext. إحدى الطرق هي إضافة InputContexts الخاصة بك إلى مجلد تحت ReplicatedStorage واستخدام Script تحت ServerScriptService لاستنساخ InputContexts لكل لاعب:

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

باستخدام هذا النمط، يمكنك قراءة InputActions لكل اللاعبين في RunService:BindToSimulation() على كل من العميل والخادم لاستقبال نفس البيانات لإطار معين وتسجيل المدخلات السابقة للإطار في خصيصة، على سبيل المثال لتفعيل تشغيل الشخصية عند تفعيل إجراء RunAction.

لاحظ أنه إذا كنت بحاجة إلى كتابة بيانات مخصصة إلى نظام إجراءات المدخلات، يجب عليك استخدام وظيفة مرتبطة بـ RunService.RenderStepped أو RunService:BindToRenderStep(), وليس RunService:BindToSimulation(). قد يؤدي إطلاق InputAction في BindToSimulation() إلى جعل العملاء ينتجون نتائج غير صحيحة خلال إعادة المحاكاة.

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

RunService:BindToRenderStep("CameraInput", Enum.RenderPriority.Last.Value, function()
	-- أرسل متجه أمام الكاميرا للعميل إلى الخادم عبر إجراء المدخلات
	local cameraForwardInputAction = Players.LocalPlayer.PlayContext.CameraForward
	local cameraForwardVector = Workspace.CurrentCamera.CFrame.LookVector
	cameraForwardInputAction:Fire(cameraForwardVector)
end)

الأحداث عن بعد

يمكن استخدام الأحداث عن بعد ضمن نموذج سلطة الخادم لتسهيل الاتصال المتقطع بين العميل والخادم. على سبيل المثال، يمكن للخوادم استخدام الأحداث عن بعد لبث بيانات حول اللاعبين الذين يسجلون نقاطًا أو يلتقطون كائنات، ويمكن للعملاء استخدام الأحداث عن بعد كواجهة برمجة تطبيقات بديلة لإرسال المدخلات إلى الخادم، مثل الضغط على الأزرار أو النقر على الكائنات في العالم ثلاثي الأبعاد.

الرسوم المتحركة والأصوات والتأثيرات

يجب كتابة التأثيرات الجانبية مثل الرسوم المتحركة والأصوات مع العلم بأن محاكاة العميل هي مجرد تصوّر للحالة الموثوقة للخادم. يحدد BindToSimulation() ما الخصائص والطرق التي يمكن استدعاؤها من داخل الدوال المرتبطة للمساعدة في توجيهك لكتابة فقط إلى حالة المحاكاة المتزامنة. يجب تنفيذ نتائج هذه المحاكاة، وتفعيل التأثيرات والأصوات، وما إلى ذلك، في وظيفة منفصلة مرتبطة بـ RenderStepped التي تقرأ نتائج المحاكاة وتفعل التأثيرات المرغوبة.

يتم تغطية المزيد من الإرشادات حول عرض محاكاة متوقعة في دليل التقنيات المتقدمة.

مشاريع نموذجية

بالإضافة إلى هذه الوثائق، يمكن أن تساعدك القوالب التالية في البدء: