چرا نقش‌های وردپرس در سایت‌های آموزش بازی‌سازی نیاز به تنظیمات بازی دارند؟

نقش‌های وردپرس در سایت‌های آموزش بازی‌سازی به‌دلیل نیاز به مدیریت Build بازی، خط لوله دارایی (Asset Pipeline)، محیط پلی‌تست، و کنترل نسخه موتور بازی، تنظیمات بازی اختصاصی می‌خواهند. یک دانشجوی بازی‌سازی باید بتواند Build خود را بسازد، در محیط تست اجرا کند، و بازخورد پلی‌تست دریافت کند، بدون اینکه به پروژه سایر دانشجویان دسترسی پیدا کند یا منابع Build Server را بیهوده مصرف کند. این تعادل میان دسترسی به Pipeline و حفاظت از دارایی‌های بازی، ریشه اصلی نیاز به معماری نقش مبتنی بر بازی است.

نخستین بار که سایت آموزش بازی‌سازی را روی وردپرس راه‌اندازی کردم، با یک بحران روبه‌رو شدم: یکی از دانشجویان Build بازی خود را روی سرور اصلی اجرا کرد و به‌دلیل یک باگ در حلقه بازی، کل CPU سرور اشغال شد. آن تجربه نشان داد که مدیریت Build و اجرای بازی، نیازمند یک لایه ایزوله است که در نقش‌های پیش‌فرض وردپرس وجود ندارد.

چرا نقش‌های پیش‌فرض کافی نیستند؟

وردپرس شش نقش پیش‌فرض دارد که حول مدیریت محتوا ساخته شده‌اند. در سایت آموزش بازی‌سازی، این نقش‌ها با شکاف‌های زیر روبه‌رو می‌شوند:

• نبود مدیریت Build: هیچ مکانیزمی برای Build کردن پروژه و ذخیره خروجی وجود ندارد.
• نبود محیط پلی‌تست ایزوله: اجرای بازی روی سرور اصلی خطرناک است.
• نبود تفکیک Asset Pipeline: دارایی‌های بازی (مدل، تکسچر، صدا) ساختار دسترسی متفاوتی دارند.
• ریسک نقض لایسنس Asset Store: دارایی‌های پولی باید کنترل‌شده در اختیار دانشجویان قرار بگیرند.

در سایت آموزش بازی‌سازی، Build یک دارایی فکری است، نه یک فایل اجرایی ساده.

اگر با مفاهیم پایه نقش و دسترسی آشنا نیستید، مطلب مدیریت نقش‌ها و دسترسی‌ها در وردپرس را ببینید. برای درک ایزوله‌سازی، مطلب افزایش امنیت سرور را مطالعه کنید.

نقش‌ها در سایت آموزش بازی‌سازی

دانشجو (Game Dev Student)

دسترسی به پروژه شخصی، Build محدود، پلی‌تست شخصی، بدون دسترسی به پروژه سایرین.

مدرس (Game Dev Instructor)

مشاهده همه پروژه‌ها، اجرای پلی‌تست، ثبت بازخورد، بدون دسترسی به Build Server اصلی.

مدیر فنی (Technical Director)

مدیریت Pipeline، استانداردهای فنی، دسترسی به Build Server.

مدیر Build (Build Manager)

مدیریت صف Build، تخصیص منابع، پایش مصرف.

پلی‌تستر (Playtester)

دسترسی محدود به Build برای تست، ثبت گزارش باگ، بدون دسترسی به کد مبدأ.

چالش‌های دارایی بازی

۱. حجم بالای Build

یک Build بازی می‌تواند چند گیگابایت باشد. فایل‌ها در Object Storage نگهداری می‌شوند و فقط نسخه‌های فشرده برای پلی‌تست در وردپرس هستند.

۲. اجرای ایزوله بازی

بازی نباید روی سرور اصلی اجرا شود. باید در یک محیط Cloud Gaming یا Container با GPU محدود اجرا شود.

۳. صف Build

Build یک عملیات پرهزینه است. باید صف FIFO با محدودیت زمانی و سهمیه روزانه وجود داشته باشد.

۴. Asset Store و لایسنس

دارایی‌های پولی از Asset Store لایسنس محدود دارند. باید یک لایه کنترل دسترسی داشته باشیم. برای مطالعه بیشتر، مطلب GitHub در پروژه‌های تیمی را ببینید.

۵. کنترل نسخه پروژه

هر پروژه چندین نسخه دارد. این چرخه نیازمند Version Control است.

تنظیمات بازی هر نقش

پیاده‌سازی با PHP

ابتدا CPT پروژه بازی را می‌سازیم. برای مطالعه بیشتر، مطلب پیاده‌سازی درست Custom Post Type را ببینید.

function wk_register_game_cpt() {
    register_post_type('wk_game_project', array(
        'label' => 'پروژه‌های بازی',
        'public' => false,
        'show_ui' => true,
        'capability_type' => 'wk_game_project',
        'capabilities' => array(
            'read_post' => 'read_wk_game_project',
            'edit_post' => 'edit_wk_game_project',
            'edit_posts' => 'edit_wk_game_projects',
            'edit_others_posts' => 'edit_others_wk_game_projects',
        ),
        'map_meta_cap' => true,
        'supports' => array('title', 'editor', 'author', 'custom-fields'),
    ));
}
add_action('init', 'wk_register_game_cpt');

سپس نقش‌های سفارشی را می‌سازیم. برای درک هوک‌ها، مطلب هوک‌های وردپرس را ببینید.

function wk_register_game_roles() {
    add_role('wk_game_student', 'دانشجوی بازی‌سازی', array(
        'read' => true,
        'edit_wk_game_projects' => true,
        'publish_wk_game_projects' => true,
        'queue_wk_build' => true,
        'upload_files' => true,
    ));

    add_role('wk_game_instructor', 'مدرس بازی‌سازی', array(
        'read' => true,
        'edit_wk_game_projects' => true,
        'edit_others_wk_game_projects' => true,
        'queue_wk_build' => true,
        'read_wk_playtest_feedback' => true,
        'edit_wk_playtest_feedback' => true,
    ));

    add_role('wk_build_manager', 'مدیر Build', array(
        'read' => true,
        'manage_wk_build_queue' => true,
        'allocate_wk_gpu' => true,
    ));

    add_role('wk_playtester', 'پلی‌تستر', array(
        'read' => true,
        'run_wk_playtest' => true,
        'submit_wk_bug_report' => true,
    ));
}
add_action('init', 'wk_register_game_roles');

برای انتخاب افزونه مدیریت کاربران، مطلب انتخاب افزونه مدیریت کاربران وردپرس را ببینید.

خط لوله Build

مدیریت Build مهم‌ترین بخش است. الگوی پیشنهادی:

function wk_queue_build_job($user_id, $project_id, $target_platform) {
    if (!current_user_can('queue_wk_build')) {
        return new WP_Error('forbidden', 'دسترسی غیرمجاز');
    }
    $quota = wk_get_build_quota($user_id);
    if ($quota['used_today'] >= $quota['daily_limit']) {
        return new WP_Error('quota_exceeded', 'سهمیه Build تمام شد');
    }
    $job_id = wp_insert_post(array(
        'post_type' => 'wk_build_job',
        'post_status' => 'pending',
        'post_author' => $user_id,
        'post_title' => sprintf('Build for Project #%d', $project_id),
    ));
    update_post_meta($job_id, 'wk_project_id', $project_id);
    update_post_meta($job_id, 'wk_target_platform', sanitize_key($target_platform));
    update_post_meta($job_id, 'wk_job_status', 'queued');
    return $job_id;
}

نکته کلیدی: Build باید در یک Worker جدا (مثلاً Jenkins یا GitLab Runner) اجرا شود، نه در وردپرس. وردپرس فقط Job ایجاد می‌کند.

پلی‌تست و بازخورد

گزارش باگ نیازمند ساختار دقیق است:

function wk_save_bug_report($project_id, $tester_id, $data) {
    $reports = get_post_meta($project_id, 'wk_bug_reports', true);
    if (!is_array($reports)) {
        $reports = array();
    }
    $reports[] = array(
        'tester_id' => $tester_id,
        'severity' => sanitize_key($data['severity']),
        'description' => sanitize_textarea_field($data['description']),
        'step_to_reproduce' => sanitize_textarea_field($data['step']),
        'build_version' => sanitize_text_field($data['build']),
        'timestamp' => current_time('mysql'),
    );
    update_post_meta($project_id, 'wk_bug_reports', $reports);
}

برای مطالعه بیشتر درباره متادیتا، مطلب کار با User Meta در وردپرس را ببینید. برای درک چرخه بازخورد، مطلب فیلدهای سفارشی ACF مفید است.

امنیت و لایسنس

سه لایه امنیتی ضروری است:

1. اعتبارسنجی نوع فایل آپلودی (UnityPackage، uasset، FBX، OBJ).
2. ذخیره Buildها در Object Storage با Token موقت.
3. اجرای بازی در محیط ایزوله (Container یا Cloud Gaming).

برای مطالعه بیشتر درباره امنیت فایل، مطلب توابع وردپرس برای کار با فایل‌ها را ببینید. استاندارد OWASP مرجع اصلی امنیت آپلود فایل است.

پرسش‌های پرتکرار

آیا می‌توانم از نقش Editor برای مدرس بازی‌سازی استفاده کنم؟

خیر. Editor به همه پست‌ها دسترسی دارد، از جمله به Buildهای ناتمام. باید نقش سفارشی با محدودیت دامنه بسازید.

بهترین روش برای ذخیره Build بازی چیست؟

Object Storage (S3، Cloudflare R2)، CDN برای توزیع، و لینک امضاشده با انقضا. هرگز Build مستقیم در uploads نگه ندارید.

چگونه از انحصار GPU جلوگیری کنم؟

صف FIFO با محدودیت زمانی و سهمیه روزانه. برای مطالعه بیشتر، مطلب تخصیص منابع سرور را ببینید.

آیا استفاده از موتورهای بازی در وب ممکن است؟

بله با WebGL و WebAssembly. اما برای آموزش حرفه‌ای، محیط دسکتاپ لازم است.

اشتباهات رایج

نگاه مهندسی سطح‌بالا

در معماری یک پلتفرم آموزش بازی‌سازی، چالش اصلی «مدیریت چرخه حیات Build در محیط چند-مستأجری» است. هر دانشجو Build اختصاصی دارد که باید در محیط خودش اجرا شود، اما منابع مشترک (Build Server، GPU) باید عادلانه توزیع شوند.

رویکرد پیشنهادی، معماری «Pipeline-as-Code» است. هر پروژه یک فایل YAML دارد که مرحله‌های Build، تست، و انتشار را تعریف می‌کند. این فایل توسط یک Runner جداگانه اجرا می‌شود و وردپرس فقط نقش Trigger و Report را دارد.

نکته دوم، بحث «Deterministic Build» است. برای اینکه خروجی Build در سیستم‌های مختلف یکسان باشد، باید تمام وابستگی‌ها (نسخه موتور، SDK، کتابخانه‌ها) ثابت شوند. این نیازمند Container Image استاندارد است.

نکته سوم، بحث «Playtest Telemetry» است. برای تحلیل رفتار بازیکن در پلی‌تست، باید داده‌های تلمتری (موقعیت، زمان، تعامل) جمع‌آوری شوند. این داده‌ها سپس به یک سیستم تحلیل جداگانه ارسال می‌شوند تا هم بار روی وردپرس کم شود و هم تحلیل حرفه‌ای ممکن باشد.

اگر این چالش‌ها را در پروژه واقعی تجربه کرده‌اید، برای من جالب است بدانم کدام بخش بیشترین زمان را گرفت: صف Build، ایزوله‌سازی پلی‌تست، یا مدیریت Asset Store. تجربه خود را در دیدگاه‌ها بنویسید.