هندسة خوادم Zero-Waste: تحليل مقترح Hibernation لتحسين خوادم Fortnite
يواجه كل مطور ألعاب Multiplayer في النهاية نفس الجدار المالي: البنية التحتية لخوادمك تحرق الأموال لمحاكاة مساحة فارغة. عندما تقوم بتشغيل Dedicated Server للعبة Battle Royale واسعة النطاق، أو لعبة بقاء، أو MMO، فإن دورات CPU تنحرف بشدة نحو حسابات الخمول. أنت تدفع أسعار Cloud Computing مميزة لحساب الجاذبية للصخور التي لا ينظر إليها أحد، ومعالجة ملاحة AI للأعداء الذين ليس لديهم أهداف، والحفاظ على World States في قطاعات خالية تمامًا من نشاط اللاعبين.
مؤخرًا، ظهر مقترح تقني رائع في مجتمع Unreal Engine موجه إلى قيادة Epic Games. الأطروحة الأساسية؟ يتطلب الحجم الهائل لـ Fortnite الانتقال من نموذج استضافة مركزي عالي الصيانة إلى نموذج "Zero-Waste Infrastructure". جادل المؤلف بأنه من خلال القضاء على هدر المحاكاة، يمكن لـ Epic تقليل Operating Expenses (Opex) بنسبة 60-70%، مما يسمح لهم نظريًا بخفض سعر العملة المميزة إلى 1.99 دولار لـ 1000 V-Bucks.
بينما تعد الجدوى الاقتصادية لتسعير V-Bucks نقاشًا لمصممي 수익، فإن الركيزة التقنية لهذا المقترح — Sector Physics Hibernation (SGH) — هي درس متقدم في هندسة الخوادم الحديثة.
في هذا التحليل للصناعة، سنقوم بتفكيك آليات مقترح Hibernation لتحسين خوادم Fortnite، واستكشاف كيفية عمل Logic-Side Culling في Unreal Engine 5، وتوضيح كيف يمكنك تنفيذ بنية تحتية Zero-Waste في ألعاب Multiplayer الخاصة بك.
رياضيات هدر المحاكاة
لفهم سبب ضرورة Sector Physics Hibernation، علينا النظر إلى الرياضيات القاسية لـ Dedicated Servers للألعاب.
خذ خريطة Battle Royale قياسية بمساحة 100 كم². في بداية المباراة، يهبط 100 لاعب في نقاط اهتمام مختلفة. خلال أول 5 دقائق، يتم إقصاء 50% من اللاعبين، ويتقارب اللاعبون الناجون نحو Safe Zone تتقلص.
بحلول الدقيقة 10، تحتوي أكثر من 70% من المساحة الإجمالية للخريطة على صفر لاعبين نشطين. ومع ذلك، في إعداد Authoritative Server قياسي، يستمر Dedicated Server في تنفيذ Tick لكامل حالة العالم بتردد 30 هرتز.
- Physics Calculations: لا تزال Rigid Bodies، والبيئات القابلة للتدمير، والمقذوفات قيد التتبع في الذاكرة.
- Actor Ticking: آلاف من نسخ
AActorتستدعي وظائفTick()الخاصة بها 30 مرة في الثانية. - NavMesh Processing: يستمر AI المتجول أو العوائق الديناميكية في الاستعلام عن Navigation Mesh.
إذا كنت تقوم بتشغيل خوادمك على مثيلات AWS c5.2xlarge، فأنت تدفع حوالي 0.34 دولار في الساعة لكل جهاز. إذا كان جهاز واحد يمكنه استضافة مثيلين فقط من الألعاب لـ 100 لاعب لأن CPU في أقصى طاقته يحسب مساحة فارغة، فإن توسعك معطل بشدة.
يقترح المقترح أنه من خلال استعادة هذا العبء الضائع من CPU، يمكن للمطورين إما حزم 5-6 مثيلات ألعاب على نفس الأجهزة (مما يخفض فواتير الخادم بنسبة 60% تقريبًا)، أو إعادة توجيه قوة المعالجة المستعادة لتعزيز Tick Rate العالمي للخادم من 30 هرتز إلى 60 هرتز+، مما يضمن Hit Registration مثاليًا وأسلوب لعب سلسًا للغاية.
تعمق: Sector Physics Hibernation في UE5
يعتمد الحل التقني المقترح على الاستفادة من نظام World Partition الموجود في Unreal Engine 5، ولكن مع قلب حالة استخدامه الأساسية من إدارة الذاكرة من جانب العميل إلى إدارة CPU من جانب الخادم.
المشكلة في Dedicated Servers الافتراضية
افتراضيًا، يقوم World Partition في UE5 ببث الخلايا للداخل والخارج للعميل بناءً على مسافتها من مصدر البث (كاميرا اللاعب). هذا ممتاز للحفاظ على انخفاض استخدام ذاكرة العميل وارتفاع معدلات الإطارات.
ومع ذلك، يقوم Dedicated Server عادةً بتحميل الخريطة بأكملها في الذاكرة للحفاظ على السلطة. إذا أطلق قناص رصاصة عبر وادٍ، أو إذا تم تفعيل حدث عالمي، يحتاج الخادم إلى بيانات التصادم و Actor States متاحة بسهولة للتحقق من الإجراء. تحميل وتفريغ البيانات ديناميكيًا من القرص على الخادم (Level Streaming) غالبًا ما يكون بطيئًا جدًا ويسبب تقطعات هائلة، مما يؤدي إلى تدمير Tick Rate.
حل SGH: Logic-Side Culling
بدلاً من تفريغ القطاع من الذاكرة (مما يسبب اختناقات IO)، يقترح Sector Physics Hibernation حالات CPU-Sleep States.
يظل القطاع في RAM، ولكن يتم إيقاف جميع الـ Ticks وحسابات الفيزياء وتحديثات الحالة بقوة. عندما تكتشف خلية Spatial Grid لقطاع ما عدم وجود كيانات نشطة (لاعبين، أو مركبات يملكها لاعبون، أو مقذوفات نشطة)، يقوم الخادم بتعليق تخصيص CPU لهذه الشبكة المحددة.
تنفيذ Hibernation Manager في C++
لبناء هذا في Unreal Engine، تحتاج إلى نظام فرعي يراقب خلايا Spatial Grid ويقوم بتبديل حالة Tick للـ Actors داخلها ديناميكيًا. فيما يلي نموذج معماري مبسط لكيفية تنفيذ SectorHibernationManager.
#include "SectorHibernationManager.h"
#include "EngineUtils.h"
#include "GameFramework/Actor.h"
#include "GameFramework/PlayerController.h"
void USectorHibernationManager::Initialize(FSubsystemCollectionBase& Collection)
{
Super::Initialize(Collection);
HibernationCheckInterval = 2.0f; // التحقق كل ثانيتين
TimeSinceLastCheck = 0.0f;
GridCellSize = 10000.0f; // خلايا شبكة 100 متر
}
void USectorHibernationManager::Tick(float DeltaTime)
{
TimeSinceLastCheck += DeltaTime;
if (TimeSinceLastCheck >= HibernationCheckInterval)
{
EvaluateSectors();
TimeSinceLastCheck = 0.0f;
}
}
void USectorHibernationManager::EvaluateSectors()
{
UWorld* World = GetWorld();
if (!World) return;
// الخطوة 1: تعيين مواقع اللاعبين النشطين إلى خلايا الشبكة
TSet<FIntVector> ActiveCells;
for (FConstPlayerControllerIterator Iterator = World->GetPlayerControllerIterator(); Iterator; ++Iterator)
{
APlayerController* PC = Iterator->Get();
if (PC && PC->GetPawn())
{
FVector PlayerPos = PC->GetPawn()->GetActorLocation();
FIntVector CellCoord = FIntVector(
FMath::FloorToInt(PlayerPos.X / GridCellSize),
FMath::FloorToInt(PlayerPos.Y / GridCellSize),
FMath::FloorToInt(PlayerPos.Z / GridCellSize)
);
// وضع علامة على هذه الخلية والخلايا المجاورة كنشطة (منطقة عازلة)
MarkAdjacentCellsActive(CellCoord, ActiveCells);
}
}
// الخطوة 2: التكرار عبر الـ Actors القابلة للسبات وتبديل الـ Tick
for (TActorIterator<AActor> ActorItr(World); ActorItr; ++ActorItr)
{
AActor* Actor = *ActorItr;
// تخطي Actors البنية التحتية الأساسية
if (!Actor->ActorHasTag(FName("Hibernatable"))) continue;
FVector ActorPos = Actor->GetActorLocation();
FIntVector ActorCell = FIntVector(
FMath::FloorToInt(ActorPos.X / GridCellSize),
FMath::FloorToInt(ActorPos.Y / GridCellSize),
FMath::FloorToInt(ActorPos.Z / GridCellSize)
);
bool bShouldBeActive = ActiveCells.Contains(ActorCell);
if (bShouldBeActive && !Actor->IsActorTickEnabled())
{
// استيقاظ
Actor->SetActorTickEnabled(true);
Actor->SetActorEnableCollision(true);
}
else if (!bShouldBeActive && Actor->IsActorTickEnabled())
{
// الذهاب للنوم
Actor->SetActorTickEnabled(false);
// اختياري: خفض التصادم إلى الاستعلامات البسيطة فقط لتوفير وقت خيط الفيزياء
Actor->SetActorEnableCollision(false);
}
}
}
تعقيد مرحلة "الاستيقاظ"
يوضح الكود أعلاه المفهوم الأساسي، لكن التحدي الهندسي الحقيقي يكمن في مرحلة الاستيقاظ. إذا أطلق لاعب بندقية قنص عالية السرعة في قطاع نائم، فسيخترق المقذوف الحدود قبل أن تلتقطه حلقة التقييم التي تستغرق ثانيتين.
إذا استيقظ القطاع بعد وصول الرصاصة، فستواجه Desync كارثيًا. قد تمر الرصاصة مباشرة عبر مركبة في حالة سبات لأن تصادمها كان معطلاً. ترتبط هذه الظاهرة تمامًا بالمشكلات المفصلة في دليلنا حول The Unreal Engine Multiplayer Sync Bug Ruining Your World States And How To Fix It، حيث تؤدي التناقضات في التوقيت بين حالة الخادم وتوقعات العميل إلى كسر المحاكاة تمامًا.
لحل هذه المشكلة، تتطلب البنية التحتية Zero-Waste وجود Predictive Wake-Ups. بدلاً من مجرد تتبع مواقع اللاعبين، يجب على الخادم حساب متجهات السرعة الأمامية لجميع المقذوفات النشطة والمركبات عالية السرعة. إذا تقاطع متجه مع خلية شبكة نائمة، يجب على الخادم فرض حدث استيقاظ فوري على تلك الخلية المحددة قبل وصول الكائن.
تنسيق خوادم Zero-Waste على نطاق واسع
إن تنفيذ Logic-Side Culling داخل محرك اللعبة هو نصف المعركة فقط. النصف الآخر هو تنسيق البنية التحتية.
إذا نجح Dedicated Server الخاص بـ UE5 في تقليل بصمة CPU بنسبة 60% ديناميكيًا، فيجب أن تكون بيئة استضافة الخادم ذكية بما يكفي للتعرف على هذا الانخفاض في استخدام الموارد وحزم مثيلات ألعاب جديدة على نفس عقدة الأجهزة.
يتطلب بناء هذا التنسيق بنفسك قدرًا هائلاً من هندسة DevOps. ستحتاج إلى نشر مجموعات Kubernetes، وتكوين Agones لإدارة دورة حياة خادم اللعبة، وكتابة مقاييس توسيع مخصصة بناءً على استخدام CPU، وإدارة Load Balancers لتوجيه اللاعبين إلى المثيلات الصحيحة. هذا عمل مخصص للبنية التحتية يستغرق بسهولة 4-6 أشهر — وهو وقت مقتطع مباشرة من بناء لعبتك.
مع horizOn، تأتي خدمات تنسيق Backend هذه مسبقة التكوين. تتعامل المنصة مع حزم المثيلات الديناميكية، و Auto-Scaling بناءً على حمل الخادم في الوقت الفعلي، وخطوط أنابيب النشر الآلية لبناء Dedicated Server الخاص بك. من خلال السماح لـ Backend-as-a-Service متخصص بالتعامل مع البنية التحتية، يمكنك شحن لعبة Multiplayer الخاصة بك بدلاً من قضاء نصف عام في القتال مع ملفات Kubernetes.
علاوة على ذلك، عندما تحزم المزيد من المثيلات على عقدة واحدة، فإنك تزيد من خطر مشاكل Noisy Neighbor التي تؤثر على خيط الشبكة الخاص بك. يعد تأمين Netcode الخاص بك ضد هذه الاختناقات أمرًا بالغ الأهمية، وهو موضوع نغطيه باستفاضة في The Uefn Server Performance Exploit Explained Hard Armoring Your Unreal Engine Netcode.
أفضل الممارسات لهندسة Multiplayer Zero-Waste
سواء كنت تبني Battle Royale لـ 100 لاعب أو لعبة بقاء في عالم مفتوح مستمر، فإن تنفيذ تقنيات Hibernation و Zero-Waste يتطلب انضباطًا معماريًا صارمًا. فيما يلي خمس ممارسات فضلى مختبرة لضمان بقاء Opex الخادم منخفضًا دون التضحية بتجربة اللاعب:
1. فصل Game State عن Tick Loop
أكبر عدو لأداء الخادم هو الاستطلاع المستمر للبيانات. لا تستخدم أبدًا Tick() للتحقق مما إذا كان يجب وقوع حدث ما. انتقل تمامًا إلى Event-Driven Architecture. إذا كانت نار المخيم بحاجة إلى الانطفاء بعد 5 دقائق، فلا تقم بعمل Tick لها في كل إطار لطرح الوقت. قم بتعيين Timer Delegate يتم تفعيله مرة واحدة بالضبط بعد 300 ثانية. يسمح هذا لـ Actor نار المخيم بالبقاء نائمًا تمامًا لمدة 4 دقائق و 59 ثانية.
2. تنفيذ NetCullDistanceSquared صارم
يحدد Unreal Engine أي Actors يتم تكرارها لأي عملاء بناءً على NetCullDistanceSquared. يترك العديد من المطورين هذا عند القيم الافتراضية، مما يجبر الخادم على تسلسل وضغط البيانات للـ Actors التي تبعد مئات الأمتار عن اللاعب. قم بمراجعة مسافات الـ Cull الخاصة بك. لا يحتاج السلاح المسقط إلى التكرار لأكثر من 5000 وحدة (50 مترًا). احسب الحد الأدنى المطلق لنصف القطر المطلوب لـ Gameplay Loop الخاص بك وفرضه بصرامة.
3. استخدام Spatial Hash Grids لعمليات بحث O(1)
عند حساب الـ Actors التي يجب أن تذهب للنوم، يصبح التكرار عبر كل Actor في العالم (TActorIterator) اختناقًا في حد ذاته إذا كان لديك 100,000 كيان. قم بتنفيذ Spatial Hash Grid. عندما يتحرك Actor، فإنه يقوم بتحديث موقعه في Hash Map. يسمح هذا لـ Hibernation Manager بالاستعلام عن "ماذا يوجد في خلية الشبكة X؟" في تعقيد زمني O(1)، مما يجعل تقييم السبات مجانيًا تقريبًا على CPU.
4. استخدام Buffer Zones لاستيقاظ سلس
لا تجعل قطاعًا يدخل في سبات أبدًا حتى حافة رؤية اللاعب مباشرة. حافظ دائمًا على "Buffer Zone" من القطاعات النشطة بعرض خلية شبكة واحدة على الأقل حول أي كيان نشط. إذا كانت خلايا الشبكة الخاصة بك بعرض 100 متر، وكان اللاعب في الخلية A، فيجب أن تظل جميع الخلايا المجاورة (شبكة 3x3) نشطة بالكامل. يضمن هذا أنه إذا ركض لاعب فجأة عبر حدود، فإن الخلية الوجهة تكون مهيأة وتعمل بالفعل.
5. تحليل أداء Dedicated Server بانتظام
لا تخمن ما الذي يستهلك CPU الخاص بك. استخدم Unreal Insights في بيئة Dedicated Server مغلفة مع حمل محاكى. انظر تحديدًا إلى توقيتات GameThread. إذا رأيت Physics أو TickTime يهيمنان على مخطط الخيط عندما يكون اللاعبون واقفين، فإن منطق السبات الخاص بك يفشل. القياس عن بعد هو الطريقة الوحيدة للتحقق من أن بنية Zero-Waste الخاصة بك تعمل في الواقع، وليس فقط في النظرية.
مستقبل Opex الخوادم
يسلط مقترح مجتمع Fortnite الضوء على حقيقة بالغة الأهمية: المعيار الحالي للصناعة المتمثل في فرض أداء الخادم باستخدام Cloud Compute باهظ الثمن غير مستدام. مع كبر العوالم وزيادة أعداد اللاعبين، فإن التوسع الخطي لتكاليف البنية التحتية سيؤدي ببطء إلى استنزاف ميزانيات Live-Ops.
لم تعد تقنيات Sector Physics Hibernation، و Logic-Side Culling، وحزم المثيلات الديناميكية مجرد تحسينات لاستوديوهات AAA؛ بل هي متطلبات بقاء لألعاب Multiplayer من جميع الأحجام. من خلال تبني عقلية Zero-Waste في وقت مبكر من دورة التطوير الخاصة بك، فإنك تضمن أن ربحية لعبتك تتوسع جنبًا إلى جنب مع قاعدة لاعبيها.
إذا كنت مستعدًا لتنفيذ توسيع الخادم الديناميكي دون صداع DevOps، فجرّب horizOn مجانًا أو راجع وثائق API لترى مدى سلاسة البنية التحتية للـ Multiplayer.