تحسين توسع ألعاب الموبايل (Mobile Game Scaling Optimization): هندسة المدن لاستيعاب أكثر من مليون لاعب متزامن

يدرك كل مطور Multiplayer اللحظة الدقيقة التي تبدأ فيها بنية اللعبة المعمارية (Architecture) بالانهيار. تقوم بتصميم بيئة حضرية مترامية الأطراف وجميلة، وتختبرها محلياً مع 10 عملاء (Clients) محاكيين، ويعمل الإصدار (Build) بمعدل 60 FPS مثالي. ثم تنقله إلى بيئة حية مع 1,000 لاعب متزامن (Concurrent Players) يزدحمون في الساحة المركزية. وفي غضون ثوانٍ، تتعرض أجهزة Android الضعيفة لـ Hard-crash بسبب استثناءات Out-Of-Memory (OOM)، ويقوم نظام iOS Jetsam بإيقاف تطبيقك بشكل هجومي، وترتفع وحدة المعالجة المركزية (CPU) في الـ Dedicated Server إلى 100% أثناء محاولتها حساب الـ Network Replication لآلاف الكيانات المتداخلة.

عند بناء لعبة Mobile MMO أو عالم مفتوح واسع النطاق مصمم لدعم ملايين المستخدمين النشطين، لا يمكنك الاعتماد على الإعدادات الافتراضية للمحرك (Engine Defaults). تمتلك أجهزة الموبايل حدوداً حرارية صارمة (Thermal Throttling) وقيوداً قاسية على الذاكرة (غالباً ما تحد من ذاكرة الوصول العشوائي RAM المتاحة للعبتك بأقل من 2GB في الأجهزة المتوسطة). وفي الوقت نفسه، يجب أن يتعامل الـ Server الخاص بك مع تجمعات اللاعبين الكثيفة دون أن ينهار.

يتطلب تحقيق تحسين حقيقي لتوسع ألعاب الموبايل (Mobile Game Scaling Optimization) نهجاً ثلاثي الأركان: تقسيم مكاني (Spatial Partitioning) مكثف على الـ Server، وإدارة صارمة للذاكرة (Memory Management) على الـ Client، وبنية Backend موزعة (Distributed Backend Architecture) للتعامل مع الحجم الهائل من الاتصالات. في هذا البرنامج التعليمي، سنقوم بتفكيك كيفية هندسة المدن الضخمة لمنصات الموبايل بدقة.

الخطوة 1: التقسيم المكاني من جانب السيرفر (Server-Side Spatial Partitioning)

العدو الأساسي لأداء الـ Server في الألعاب الضخمة متعددة اللاعبين هو مشكلة O(N²). إذا قام الـ Server الخاص بك بالمرور عبر كل لاعب للتحقق من المسافة بينه وبين كل لاعب آخر لتحديد من يحتاج إلى تحديثات الشبكة (Network Updates)، فإن الحسابات ستتزايد بشكل كارثي. 100 لاعب يتطلبون 10,000 فحص للمسافة لكل Tick. بينما 1,000 لاعب يتطلبون 1,000,000 فحص. بمعدل 30Hz لـ Server Tick Rate، يمثل ذلك 30 مليون فحص في الثانية.

لحل هذه المشكلة، يجب علينا تطبيق Spatial Hashing (أو نظام Grid/Quadtree). من خلال تقسيم المدينة إلى شبكة منطقية (Logical Grid)، يتحقق اللاعبون فقط من الـ Network Relevance تجاه الكيانات الموجودة في خليتهم الحالية والخلايا المحيطة مباشرة. هذا يقلل من كابوس O(N²) إلى عملية Grid Lookup بتكلفة O(1) متبوعة بفحص محلي مقيد للغاية.

تنفيذ Spatial Hash Grid (مثال C#)

إليك تنفيذاً عالي الكفاءة لـ 2D Spatial Hash Grid بلغة C# يمكنك تكييفه مع Unity أو Godot (عبر C#) أو Dedicated Server مخصص لإدارة تقارب الكيانات دون المرور عبر حالة العالم بأكمله.

using System.Collections.Generic;
using UnityEngine;

public class SpatialHashGrid
{
    private readonly float _cellSize;
    private readonly Dictionary<Vector2Int, HashSet<uint>> _grid;

    public SpatialHashGrid(float cellSize = 50f)
    {
        _cellSize = cellSize;
        _grid = new Dictionary<Vector2Int, HashSet<uint>>();
    }

    // Convert a world position to a grid coordinate
    private Vector2Int GetCellCoordinate(Vector3 position)
    {
        return new Vector2Int(
            Mathf.FloorToInt(position.x / _cellSize),
            Mathf.FloorToInt(position.z / _cellSize)
        );
    }

    // Add or update a player's position in the grid
    public void UpdateEntityPosition(uint entityId, Vector3 oldPosition, Vector3 newPosition)
    {
        Vector2Int oldCell = GetCellCoordinate(oldPosition);
        Vector2Int newCell = GetCellCoordinate(newPosition);

        if (oldCell != newCell)
        {
            if (_grid.ContainsKey(oldCell))
            {
                _grid[oldCell].Remove(entityId);
            }
            
            if (!_grid.ContainsKey(newCell))
            {
                _grid[newCell] = new HashSet<uint>();
            }
            _grid[newCell].Add(entityId);
        }
    }

    // Retrieve all entities in the immediate vicinity (9 cells)
    public List<uint> GetEntitiesInProximity(Vector3 position)
    {
        List<uint> nearbyEntities = new List<uint>();
        Vector2Int centerCell = GetCellCoordinate(position);

        // Loop through the 3x3 grid around the player
        for (int x = -1; x <= 1; x++)
        {
            for (int y = -1; y <= 1; y++)
            {
                Vector2Int cellToCheck = new Vector2Int(centerCell.x + x, centerCell.y + y);
                if (_grid.TryGetValue(cellToCheck, out HashSet<uint> entitiesInCell))
                {
                    nearbyEntities.AddRange(entitiesInCell);
                }
            }
        }

        return nearbyEntities;
    }
}

من خلال توجيه منطق الـ Network Replication عبر GetEntitiesInProximity الخاص بك، سيقوم الـ Server فقط بحساب المسافات الدقيقة لبضعة عشرات من اللاعبين القريبين من بعضهم البعض بنشاط، مما يقلل بشكل كبير من حمل الـ CPU ويسمح للسيرفر بالتعامل بارتياح مع آلاف اللاعبين المتزامنين في نفس الـ Instance.

الخطوة 2: إدارة الاهتمام بالشبكة (Network Interest Management)

حتى مع حل مشكلة الـ CPU في السيرفر باستخدام Spatial Hashing، لا تزال لديك مشكلة في النطاق الترددي (Bandwidth). شبكات الموبايل (4G/5G) غير مستقرة بطبيعتها، وعرضة للـ Jitter العالي، ولديها قيود صارمة على الـ Bandwidth. إرسال بيانات لـ 50 لاعباً قريباً في كل Tick سيغرق الـ Socket Buffer لجهاز الموبايل، مما يؤدي إلى حالات Desync شديدة.

إدارة الاهتمام (Interest Management) أو ما يعرف بـ Network Relevancy هي ممارسة تحديد أولويات "ما الذي" يتم إرساله عبر الشبكة. اللاعب الذي يبعد مترين ويخوض معركة يحتاج إلى 30 تحديثاً في الثانية، بينما اللاعب الذي يبعد 40 متراً ويسير في شارع مختلف يحتاج فقط إلى تحديثين في الثانية.

تجاوز Network Relevancy (مثال Unreal Engine C++)

في محرك Unreal Engine، يمكنك التحكم في ذلك من خلال تجاوز دالة IsNetRelevantFor. يتيح لك هذا استبعاد حركة مرور الشبكة (Network Traffic) بقوة بناءً على خط الرؤية (Line-of-Sight) ومستويات المسافة.

bool ACityPlayerCharacter::IsNetRelevantFor(const AActor* RealViewer, const AActor* ViewTarget, const FVector& SrcLocation) const
{
    // 1. Always relevant to ourselves
    if (RealViewer == this || ViewTarget == this)
    {
        return true;
    }

    // 2. Calculate squared distance (faster than exact distance)
    const float DistanceSquared = FVector::DistSquared(SrcLocation, GetActorLocation());

    // 3. Absolute Cull Distance (e.g., 10,000 units = 100 meters)
    const float MaxRelevancyDistSq = 100000000.0f; 
    if (DistanceSquared > MaxRelevancyDistSq)
    {
        return false;
    }

    // 4. Dynamic Network Update Frequency based on distance
    // If they are far away, we lower how often we send data
    if (DistanceSquared > 25000000.0f) // 50 meters
    {
        NetUpdateFrequency = 2.0f; // 2 updates a second
    }
    else
    {
        NetUpdateFrequency = 30.0f; // 30 updates a second
    }

    return Super::IsNetRelevantFor(RealViewer, ViewTarget, SrcLocation);
}

من خلال تغيير الـ NetUpdateFrequency ديناميكياً بناءً على المسافة، يمكنك تقليل الـ Bandwidth الصادر من السيرفر بنسبة تصل إلى 70%، مما يحافظ على باقة بيانات الموبايل للاعب ويمنع طفرات الـ Latency.

الخطوة 3: قيود ذاكرة العميل وبث الأصول (Asset Streaming)

تمتلك الـ Servers الكثير من الـ RAM، لكن الهواتف المحمولة لا تملك ذلك. يحتوي هاتف iPhone 13 على 4GB من الذاكرة الموحدة، وعادة ما يحجز نظام iOS حوالي 1.5GB إلى 2GB منها. يجب أن تكتفي لعبتك بالكامل بما يتبقى من الـ 2GB. إذا قمت بتحميل مدينة ضخمة بالكامل في الذاكرة مرة واحدة، فسيقوم نظام التشغيل بإنهاء التطبيق فوراً.

للنجاة في هذه البيئة، يجب تقسيم مدينتك إلى Chunks وبثها (Streamed) بشكل غير متزامن (Asynchronously).

• Hierarchical Level of Detail (HLODs): بدلاً من عمل Rendering لـ 50 مبنى فردياً في كتلة بعيدة من المدينة (مما يصل إلى 3,000 Draw Call)، يجب عليك دمج تلك الكتلة بالكامل في Static Mesh واحد مع Texture Atlas موحد. هذا يقلل الـ Draw Calls للهندسة البعيدة من الآلاف إلى واحد فقط.
• Addressable Asset Systems: لا تستخدم أبداً مراجع صلبة (Hard References) في أصول البيانات الأساسية الخاصة بك. إذا ظهر لاعب في "المنطقة أ"، يجب على الـ Client استخدام التحميل غير المتزامن (مثل Unity Addressables أو Unreal PrimaryAssetLabels) لتنزيل أو تحميل القوام (Textures) والـ Meshes المطلوبة لـ "المنطقة أ" فقط. ويجب تفريغ "المنطقة ب" بصرامة من الـ RAM.
• Texture Compression: اعتمد حصرياً على ASTC (Adaptive Scalable Texture Compression) للموبايل. فهو يسمح بـ Block Footprints متنوعة للغاية، مما يمنحك تحكماً دقيقاً في الذاكرة مقابل الجودة البصرية لكل Texture على حدة.

الخطوة 4: بنية Backend موزعة و Server Sharding

لا يمكن لمدينة ضخمة (Metropolis) أن تعمل على جهاز فيزيائي واحد. عند تصميم مدينة بمقياس MMO، يجب تقسيم العالم فيزيائياً عبر عدة حالات سيرفر (Server Instances) سواء كانت Shards أو Nodes. عندما يعبر لاعب جسراً من "منطقة وسط المدينة" إلى "منطقة العشوائيات"، يجب أن ينتقل اتصال العميل وحالة العالم بسلاسة بين عمليتي سيرفر مختلفتين تماماً.

بناء هذا بنفسك يتطلب إعداد عناقيد Kubernetes التي يتم تنظيمها بواسطة أنظمة مثل Agones، وعمل Database Sharding باستخدام Redis لتمرير حالة اللاعب بين الـ Server Nodes، واستخدام موازنات أحمال (UDP Load Balancers) مخصصة لانتقال الاتصال بسلاسة. تصميم هذا بشكل قوي بحيث لا يفقد اللاعبون عناصرهم أثناء الانتقال هو مهمة ضخمة—تتطلب بسهولة من 4 إلى 6 أشهر من عمل DevOps المخصص من قبل فريق هندسي خبير.

إذا لم تتعامل بشكل صحيح مع طوابير الـ RPC وكتابة قواعد البيانات أثناء عمليات النقل هذه، فستواجه حتماً فساداً في حالة البيانات (State Corruption). لقد غطينا سابقاً ميكانيكا fixing the Unreal Engine RPC replication issue breaking your states، وتلك المبادئ نفسها تنطبق مباشرة على عمليات النقل المكاني عبر الـ Server Nodes.

هنا تبرز قوة الحلول المتكاملة. مع horizOn، تأتي خدمات الـ Backend عالية التزامن هذه، ومزامنة قواعد البيانات في الوقت الفعلي، وتنظيم الـ Dedicated Servers مسبقة الإعداد. بدلاً من إنفاق ميزانيتك على هندسة وتصحيح قواعد شبكات Kubernetes، يمكنك التركيز بشكل كامل على بناء آليات اللعب في مدينتك وتحسينات الـ Client.

أفضل الممارسات لبناء عوالم المدن في ألعاب الموبايل

لضمان توسع مدينتك بسلاسة لملايين المستخدمين مع الحفاظ على معدلات إطارات عالية على الأجهزة الاقتصادية، التزم بصرامة بهذه القواعد المعمارية:

1. Aggressive Instance Pooling: لا تستخدم أبداً Instantiate() أو SpawnActor للأجسام العابرة مثل المركبات أو المشاة أو المقذوفات أثناء اللعب. تواجه معالجات الموبايل صعوبة كبيرة في تخصيص الذاكرة (Memory Allocation) وعمليات الـ Garbage Collection. قم بتجهيز Object Pools مسبقاً أثناء شاشة التحميل وتدويرها باستمرار.
2. Texture Atlasing لكتل المدينة: الـ Draw Calls هي القاتل الأساسي لـ GPUs الموبايل (التي تعمد على Tile-Based Deferred Rendering). ادمج قوام جميع أدوات الشارع العامة (سلال المهملات، المقاعد، أعمدة الإنارة) في Texture Atlas واحد كبير. يسمح هذا للمحرك بجمع معالجة مئات الأجسام في Draw Call واحدة.
3. Strict Polycount Budgets per Chunk: فرض حدود صارمة. يجب أن يظل الـ Chunk الواحد في مدينة الموبايل (مثلاً مساحة 100×100 متر) تحت 300,000 مثلث مرئي. اعتمد بشكل كبير على الـ Normal Maps بدلاً من الهندسة الخام لمحاكاة التفاصيل المعمارية.
4. تطبيق Server-Side Hibernation: تشغيل Dedicated Server لمدينة ضخمة حيث 80% من الخريطة فارغة حالياً هو طريق سريع لإفلاس الاستوديو الخاص بك. تحتاج إلى إدارة مكثفة للـ Instances، مستلهماً من Fortnite server optimization hibernation proposal لإيقاف إحداثيات الشبكة الخاملة وإيقاظها فوراً عند اقتراب لاعب.
5. فصل الـ Collision عن الـ Visual Mesh: لا تستخدم أبداً Meshes بصرية معقدة لحسابات الـ Collision من جانب السيرفر. يجب أن يفهم الـ Server المدينة فقط كمجموعة من الأشكال الأولية منخفضة المضلعات (Low-poly primitives) مثل الصناديق والكبسولات والكرات. هذا يحافظ على استهلاك الذاكرة في السيرفر عند حده الأدنى ويجعل حسابات الفيزياء تستغرق أقل من ميلي ثانية.

فخاخ شائعة يجب تجنبها

• فخ إغراق الـ RPC: غالباً ما يقوم المطورون بتشغيل RPCs من السيرفر إلى العميل للتأثيرات البصرية (مثل شرارة منبعثة من حادث سيارة). لا تفعل ذلك. يجب على السيرفر فقط عمل Replicate لحالة السيارة (مثل bIsCrashed = true). ويجب على العميل ملاحظة هذا التغيير في الحالة بشكل مستقل عبر OnRep/property hook وتشغيل الـ VFX محلياً. هذا يوفر كميات هائلة من الـ Network Bandwidth.
• تسريب الذاكرة عند انتقال المناطق: عند إخراج Chunk من المدينة من الذاكرة على الموبايل، تأكد من أنك تفرض الـ Garbage Collection أو تقوم بإلغاء تحميل الـ Asset Bundles يدوياً. إذا تركت حتى بضع ميجابايتات من القوام المفقودة في الذاكرة في كل مرة ينتقل فيها اللاعب بين المناطق، فستنهار اللعبة حتماً بعد 20 دقيقة من اللعب.

الخلاصة

تحقيق تحسين توسع ألعاب الموبايل هو عملية موازنة دقيقة. يتطلب الأمر القتال من أجل كل ميجابايت من ذاكرة العميل (RAM)، والتنظيم الصارم للـ Network Relevancy، وتوزيع حمل السيرفر عبر Nodes خلفية قابلة للتوسع. من خلال تطبيق Spatial Hashing، وترددات التحديث الديناميكية، وبث الأصول غير المتزامن، يمكنك بناء مدن ضخمة ونابضة بالحياة تعمل بسلاسة حتى على أجهزة الموبايل القديمة.

ومع ذلك، فإن بناء البنية التحتية القابلة للتوسع لتوجيه آلاف الاتصالات المتزامنة وإدارة عمليات النقل السلسة بين السيرفرات غالباً ما يكون أصعب من بناء اللعبة نفسها. هل أنت مستعد لتوسيع الـ Multiplayer Backend الخاص بك دون كابوس الـ DevOps؟ جرب horizOn مجاناً أو اطلع على API docs لترى كيف نتعامل مع هندسة التزامن العالي بشكل جاهز.

---

المصدر: Designing Large-Scale Mobile Game Cities: Production, Optimization, & Worldbuilding Expertise