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

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

المزايا

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

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

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

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

الإعداد

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

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

المفاهيم

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

توقع العميل

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

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

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

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

العودة وإعادة المحاكاة

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

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

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

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

التنفيذ

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

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

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

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

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

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

ModuleScript يسمى Simulation في ReplicatedStorage:

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 حرفًا كحد أقصى.

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

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

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

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

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

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.

الأحداث البعيدة

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

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

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

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

مشاريع أمثلة

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