چرا این مقاله را بخوانید؟
اگر معمار نرم‌افزار، توسعه‌دهنده بازی یا فعال حوزه گیم هستید، این مقاله به شما نشان می‌دهد که چرا بازی Fortnite با ۱۱۰ میلیون بازیکن ماهانه، موفق شد و Anthem با ۵۹ امتیاز متاکریتیک، سرورهایش را در ژانویه ۲۰۲۶ خاموش کرد!
۷ الگوی معماری که در این مقاله استخراج شده، نقشه راهی عملی برای ساخت بازی‌های سرویس‌محور است.
هدف از نگارش این پژوهش، واکاوی نقش معماری نرم‌افزار در موفقیت بازی‌های سرویس‌محور است. بدین منظور، نوزده منبع معتبر شامل مقالات علمی، گزارش‌های صنعتی، مستندات فنی و مصاحبه‌های تخصصی با بهره‌گیری از روش مرور ساختاریافته ادبیات، مورد تحلیل و بررسی قرار گرفته‌اند.
یافته‌های حاصل نشان می‌دهند که هفت الگوی معماری کلیدی در بازی‌های موفق سرویس‌محور اعم از : معماری میکروسرویس، محاسبات لبه، معماری سرور-معتبر، انتقال میزبان، تحویل هوشمند، معماری رویدادمحور و محاسبات بدون سرور قابل شناسایی می‌باشند. از میان این هفت الگو، پنج الگوی نخست، نقشی حیاتی در موفقیت بازی ایفا می‌کنند.
تحلیل تطبیقی بازی فورتنایت (موفق) و آنتم (ناموفق) نشان می‌دهد که فورتنایت در تمامی هفت الگوی معماری به موفقیت دست یافته است و با در اختیار داشتن حدود یکصد و ده میلیون بازیکن ماهانه و حدود پنج و هشت دهم میلیارد دلار درآمد سالانه، به یکی از موفق‌ترین بازی‌های تاریخ بدل گشته است. در مقابل، آنتم با کسب نمره پنجاه و نه از صد در وب‌سایت متاکریتیک و خاموشی سرورهای خود در دوازدهم ژانویه سال دو هزار و بیست و شش، به یکی از بزرگ‌ترین شکست‌های صنعت بازی تبدیل شده است.
نتیجه‌گیری نهایی آن است که معماری مناسب، شرطی لازم برای موفقیت به شمار می‌رود، اما به تنهایی کافی نمی‌باشد. موفقیت در بازی‌های سرویس‌محور، حاصل آمیزه‌ای از معماری درست، مدیریت صحیح، تیم متخصص، مدل درآمدی مناسب و مهم‌تر از همه، احترام به بازیکنان است.
کلمات کلیدی: Games-as-a-Service، معماری نرم‌افزار، فورتنایت، آنتم، بازی‌های ابری، میکروسرویس، محاسبات لبه
اکوسیستم بازی‌های ویدئویی در روزگار کنونی، از اقتصاد بسیاری از کشورها فراتر رفته است. بر اساس گزارش‌های صنعتی، ارزش این اکوسیستم در سال دو هزار و بیست و چهار، از دویست میلیارد دلار عبور نموده و پیش‌بینی می‌شود که تا سال دو هزار و سی، به بیش از سیصد میلیارد دلار دست یابد. در قلب این تغییرات، مدل Games-as-a-Service جای گرفته است؛ مدلی که در آن بازی‌ها به‌جای آنکه محصولی یک‌بارفروش باشند، به‌عنوان سرویسی پیوسته با به‌روزرسانی‌های منظم و محتوای تازه ارائه می‌گردند.
در مدل سنتی، پس از انتشار بازی، کار توسعه، پایان‌یافته تلقی می‌شد. اما در مدل سرویس‌محور، انتشار بازی نقطه‌آغاز فصلی جدید است بازی‌هایی چونFortnite، Genshin Impact و Call of Duty: Warzone، با ارائه محتوای نو، رویدادهای زنده و تعامل مستمر با بازیکنان، توانسته‌اند سال‌ها در صدر جدول محبوب‌ترین بازی‌ها باقی بمانند. اما در سوی مقابل، بازی‌هایی مانندAnthem، Concord ، The Day Before، با وجود وعده‌های بزرگ، در مدت زمانی کوتاه با شکست مواجه گشتند و به عمر خود پایان دادند.
برای انجام این پژوهش، از روش مرور ساختاریافته ادبیات با رویکرد تحلیل تطبیقی بهره گرفته شده است. این روش برای پژوهش‌هایی مناسب است که هدف از آنها شناسایی الگوهای تکراری از میان منابع پراکنده و انجام تحلیل تطبیقی عمیق می‌باشد [۱].
دلیل انتخاب این روش، تنوع منابع، ماهیت میان‌رشته‌ای موضوع و هدف پژوهش بوده است. منابع این پژوهش شامل مقالات علمی، گزارش‌های صنعتی، مستندات فنی و مصاحبه‌های تخصصی هستند که هر یک نیازمند رویکرد تحلیلی متفاوتی می‌باشند.
پژوهش حاضر در پی پاسخ به این پرسش اصلی است:
آیا معماری نرم‌افزار به تنهایی می‌تواند موفقیت یک بازی سرویس‌محور (GaaS) را تضمین نماید؟
برای پاسخ به این پرسش، سه زیرپرسش نیز مطرح شده‌اند:
۱. چه مدل‌ها و الگوهای معماری در بازی‌های GaaS وجود دارند؟
۲. چه عواملی در موفقیت یا شکست معماری یک بازی GaaS نقش ایفا می‌کنند؟
۳. چه درس‌هایی از مقایسه تطبیقی فورتنایت (موفق) و آنتم (ناموفق) برای توسعه‌دهندگان GaaS قابل استخراج می‌باشند؟
۲-۳. استراتژی انتخاب منابع
برای انتخاب منابع، از رویکردی ترکیبی بهره گرفته شده است. ابتدا مقاله بنیادین کای و همکاران [۱] به‌عنوان نخستین مقاله جامع در حوزه معماری GaaS شناسایی گردید و سپس با بررسی ارجاعات به این مقاله، منابع بعدی با روش برفکی یافت شدند. در مرحله پسین، با جستجوی کلیدواژه‌های تخصصی در پایگاه‌های دادهداده IEEE Xplore، ACM Digital Library و Google Scholar، منابع بیشتری شناسایی شدند.
از میان سی و دو منبع اولیه، نوزده منبع بر اساس معیارهای مشخصی گزینش شدند. این معیارها شامل مرتبط بودن با معماری فنی بازی‌های سرویس‌محور، دارا بودن داده‌های عددی یا تحلیل ساختاریافته، داشتن مطالعه موردی از بازی‌های واقعی، و معتبر بودن منبع می‌باشند. بازه زمانی منابع از سال دو هزار و چهارده تا دو هزار و بیست و شش را در بر می‌گیرد. منابع صرفاً مدیریتی یا بازاریابی فاقد داده‌های فنی، منابع تکراری، و منابع مرتبط با بازی‌های سنتی از مجموعه حذف شده‌اند.
۲-۴. فرآیند تحلیل
پس از انتخاب منابع نهایی، فرآیند تحلیل در چهار مرحله انجام پذیرفت:
مرحله اول: مطالعه اولیه و خلاصه‌نویسی - هر منبع یک‌بار کامل خوانده شد و خلاصه‌ای از آن تهیه گردید.
مرحله دوم: کدگذاری موضوعی - مفاهیم کلیدی هر منبع استخراج و برچسب‌گذاری شدند. نمونه کدها: "مدل معماری"، "زیرساخت ابری"، "الگوی درآمدزایی"، "عامل شکست" است.
مرحله سوم: دسته‌بندی و ترکیب - کدهای مشابه در چهار دسته اصلی ترکیب شدند: مدل‌های معماری [۱، ۲، ۳]، زیرساخت و کاهش تأخیر [۴، ۷، ۱۱]، مطالعه موردی موفق [۱۰، ۱۱، ۹]، و مطالعه موردی ناموفق است [۱۴، ۱۵، ۱۶].
مرحله چهارم: تحلیل تطبیقی - مقایسه یافته‌های منابع مختلف برای شناسایی الگوهای تکراری انجام شد.
برای افزایش اعتبار یافته‌ها، از مثلث‌سازی داده‌ها بهره گرفته شده است؛ به این معنا که از منابع متنوع (مقالات علمی، گزارش‌های صنعتی، مصاحبه‌های تخصصی و مستندات فنی) برای تأیید یافته‌ها از چند منظر استفاده گردیده است.
مقاله کای و همکاران [۱] یکی از مهم‌ترین و بنیادی‌ترین منابع در حوزه GaaS به شمار می‌رود که به‌عنوان نخستین کار جامع در زمینه طبقه‌بندی معماری‌های GaaS شناخته می‌شود. نویسندگان با نگاهی سیستماتیک، سه مدل معماری متفاوت را معرفی می‌کنند.
مدل نخست: RR-GaaS
در این مدل، همه ماژول‌های بازی شامل منطق، رندرینگ و رمزگذاری در ابر اجرا می‌شوند و تنها ویدیوی نهایی به دستگاه کاربر ارسال می‌گردد. این مدل به پهنای باند بالا و تأخیر کم نیاز دارد و تأخیر قابل تحمل آن کمتر از 120میلی‌ثانیه است. مزیت اصلی این مدل آن است که کاربر به سخت‌افزار قدرتمندی نیاز ندارد و بازی در برابر دزدی مصون می‌ماند. اما پهنای باند بسیار بالا، حساسیت به تأخیر و هزینه بالای سرور از معایب آن به شمار می‌روند. نمونه‌های صنعتی این مدل شامل OnLive، Gaikai و G-Cluster می‌باشند.
مدل دوم: LR-GaaS
در این مدل، منطق بازی در سرور ابری اجرا می‌شود، اما رندرینگ و نمایش ویدیو در دستگاه کاربر انجام می‌گیرد. این مدل به پردازنده گرافیکی مناسب در دستگاه کاربر نیاز دارد. مزایای آن کاهش بار شبکه، تأخیر کمتر، کیفیت بالاتر و هزینه کمتر برای ارائه‌دهنده است. اما نیاز به سخت‌افزار گرافیکی، طراحی مجموعه دستورات، وابستگی به سیستم‌عامل و امنیت کمتر از معایب آن به شمار می‌روند.
مدل سوم: CRA-GaaS
در این مدل، برنامه بازی به مؤلفه‌های مستقل تقسیم می‌شود و هر مؤلفه می‌تواند به‌صورت پویا میان ابر و دستگاه کاربر جابه‌جا گردد. این مدل انعطاف‌پذیری بالا، بهره‌وری بهینه از منابع و تعمیم‌پذیری دارد و برای بازی‌های موبایل مناسب می‌نماید. اما پیچیدگی بالای پیاده‌سازی، هماهنگی مؤلفه‌ها و همگام‌سازی داده از معایب آن هستند.
نکته شایان توجه آن است که نوع بازی تأثیری مستقیم بر انتخاب معماری مناسب دارد. بازی‌های تیراندازی اول شخص و استراتژی لحظه‌ای به دلیل نیاز به تأخیر کم، معماری LR-GaaS یا CRA-GaaS را ترجیح می‌دهند، در حالی که بازی‌های نقش‌آفرینی نوبتی و مدیریتی به دلیل تحمل تأخیر بالاتر، می‌توانند از RR-GaaS بهره ببرند.
مقاله امینی و همکاران [۲] که در یکی از کنفرانس‌های داخلی ایران منتشر گردیده، در پی طراحی و پیاده‌سازی زیرساختی جامع و بزرگ‌مقیاس برای ارائه خدمات توسعه بازی است. نویسندگان معماری هفت‌لایه‌ای پیشنهاد می‌دهند که از کلاینت تا حاکمیت و نظارت را پوشش می‌دهد.
لایه نخست، کلاینت است که شامل دستگاه‌های مختلف مانند کامپیوتر شخصی، موبایل، کنسول و تبلت می‌شود. لایه دوم، شبکه است که شامل CDN، سرورهای لبه، متعادل‌کننده‌های بار و دروازه‌ها می‌گردد. لایه سوم، یکپارچه‌سازی سرویس‌هاست که شامل Enterprise Service Bus و Message Broker می‌شود. لایه چهارم، چرخه حیات توسعه است که مدیریت API، توسعه و DevOps را در بر می‌گیرد. لایه پنجم، سرویس‌های پایه مانند هوش مصنوعی، رسانه، واقعیت مجازی و واقعیت افزوده هستند. لایه ششم، داده است که شامل پایگاه‌های داده SQL و NoSQL و ذخیره‌سازی فایل می‌شود. لایه هفتم، حاکمیت و نظارت است که شامل سیاست‌های حاکمیتی و پایش سرویس‌ها می‌گردد.
مقالات [۱] و [۲] دو رویکرد مکمل اما متفاوت به معماری GaaS ارائه می‌دهند. مقاله [۱] از منظر مدل‌های اجرایی به مسئله می‌نگرد و سه معماری RR-GaaS، LR-GaaS و CRA-GaaS را بر اساس محل اجرای مؤلفه‌های بازی (ابر در برابر کلاینت) دسته‌بندی می‌کند. در مقابل، [۲] رویکردی سیستمی‌تر دارد و زیرساختی جامع هفت‌لایه را از کلاینت تا حاکمیت و نظارت ارائه می‌دهد.
به عبارت دیگر،[۱] به این می‌پردازد که "چه چیزی" در کجا اجرا شود ، در حالی که [۲] به این می‌پردازد که "چگونه" زیرساخت لازم برای پشتیبانی از بازی‌های سرویس‌محور باید باشد. این دو مقاله مکمل یکدیگرند
مقاله [۳] به‌صورت عملی به مقایسه دو رویکرد معماری در بازی‌های ابری می‌پردازد. در معماری یکپارچه، همه سیستم‌های بازی مانند رندرینگ، فیزیک و منطق در یک نمونه اجرا می‌شوند. در معماری توزیع‌شده، سیستم‌های بازی از هم جدا شده و به‌صورت سرویس‌های مستقل اجرا می‌گردند.
نتایج آزمایش‌های این مقاله نشان می‌دهد که در سناریوهای با تعداد اشیاء بالا، معماری توزیع‌شده عملکردی بهتر دارد. برای نمونه، در سناریوی دو هزار شیء، معماری توزیع‌شده حدود 5.26 میلی‌ثانیه سریع‌تر از معماری یکپارچه عمل نموده است. همچنین، یک سرور بهینه‌شده برای محاسبات، تقریباً 2.3 برابر سریع‌تر از یک سرور تخصصی گرافیکی، محاسبات فیزیک را انجام می‌دهد. این یافته‌ها نشان می‌دهند که برای بازی‌های سرویس‌محور با تعداد بالای موجودیت‌ها، معماری توزیع‌شده انتخابی بهتر است.
بر اساس مرور نظام‌مند بیست منبع و تحلیل تطبیقی فورتنایت و آنتم، هفت الگوی معماری تکراری در بازی‌های موفق سرویس‌محور شناسایی گردیده است. در ادامه، هر یک از این الگوها با جزییات بیشتری بررسی می‌شوند.
معماری میکروسرویس به معنای جداسازی سرویس‌های بازی به‌عنوان واحدهایی مستقل است که هر یک می‌توانند به‌طور جداگانه توسعه، استقرار و مقیاس‌دهی شوند. بر اساس مقاله [۳]، معماری توزیع‌شده در سناریوهای سنگین عملکردی بهتر از معماری یکپارچه دارد. در آزمایش‌های این مقاله، معماری توزیع‌شده در سناریوی دو هزار شیء، پنج و بیست و شش میلی‌ثانیه سریع‌تر از معماری یکپارچه بود.
مطابق با مقاله [۲]، یک زیرساخت GaaS موفق باید از لایه یکپارچه‌سازی سرویس‌ها پشتیبانی نماید. نویسندگان تأکید می‌کنند که موتورهای بازی یکپارچه مانند فراست‌بایت، نمی‌توانند از مزایای معماری سرویس‌گرا بهره‌مند شوند.
فورتنایت با معماری میکروسرویس به موفقیت دست یافت، در حالی که آنتم با معماری یکپارچه فراست‌بایت شکست خورد. این تفاوت در رویکرد، یکی از مهم‌ترین دلایل موفقیت فورتنایت و شکست آنتم به شمار می‌رود.
محاسبات لبه به معنای قرار دادن سرورهای بازی در نزدیکی کاربران برای کاهش تأخیر است. مقاله [۷] نشان می‌دهد که محاسبات لبه می‌تواند تأخیر را تا 25 میلی‌ثانیه نسبت به محاسبات ابری کاهش دهد. نتایج حاکی از آن است که حداقل تأخیر ممکن در بازی‌های لبه حدود 46 میلی‌ثانیه و در بازی‌های ابری حدود 71 میلی‌ثانیه می‌باشد.
گزارش [۱۱] نشان می‌دهد که فورتنایت با استفاده از بیست و شش منطقه در دسترس در AWS، سرورهای خود را در نزدیکی کاربران در سراسر جهان مستقر نموده است. این در حالی است که آنتم با سرورهای متمرکز EA، تأخیر بالایی داشت.
معماری سرور-معتبر به معنای اعتبارسنجی همه اقدامات در سمت سرور است. در بازی‌های چندنفره، این الگو برای جلوگیری از تقلب حیاتی می‌باشد. اگر اقدامات بازیکنان تنها در دستگاه خودشان اعتبارسنجی شود، بازیکنان می‌توانند با دستکاری کد، امتیاز بگیرند یا به دیگران زیان برسانند.
مطابق با وایت‌پیپر متاپلی [۱۰]، فورتنایت از معماری سرور-معتبر استفاده می‌کند و همه اقدامات بازیکنان در سرورهای AWS تأیید می‌شود. به نقل از تیمو هیلای، مدیر محصول متاپلی: "اگر چیزی در بازی شما ارزش خرید داشته باشد، کسی سعی می‌کند از طریق تقلب به آن دست یابد، تنها دفاعی که واقعاً کار می‌کند، معماری سرور-معتبر است." در مقابل، آنتم پیاده‌سازی ضعیفی از این الگو داشت که به مشکلات متعددی در بازی انجامید.
انتقال میزبان به معنای قابلیت انتقال میزبان به سرور دیگر در صورت قطعی است. این الگو برای بازی‌های چندنفره حیاتی می‌نماید تا وقتی یک سرور دچار مشکل می‌شود، بازی متوقف نگردد.
مارک دارا، تهیه‌کننده اجرایی سابق BioWare، در مصاحبه با GameSpot در 2025 به صراحت اعتراف نموده است: "ما نمی‌دانستیم چگونه انتقال میزبان را انجام دهیم، و صادقانه بگویم توانایی مالی آن را نیز نداشتیم." او به Destiny اشاره می‌کند که این فناوری را به‌درستی پیاده‌سازی نموده است. این در حالی است که Fortnite با استفاده از سرورهای اختصاصی AWS از این قابلیت پشتیبانی کامل می‌کند.
تحویل هوشمند به معنای مدیریت حجم بازی با قابلیت نصب انتخابی بخش‌هاست. بازی‌های امروزی بسیار بزرگ شده‌اند و دانلود و نصب کامل آنها زمان‌بر است. با استفاده از این الگو، بازیکن می‌تواند تنها بخش‌هایی از بازی را که نیاز دارد نصب نماید.
مستندات Microsoft GDK [۱۹] نشان می‌دهد که فورتنایت از این قابلیت بهره می‌برد و حجم بازی را مدیریت نموده است، در حالی که حجم آنتم بیش از 100 گیگابایت بود و این موضوع برای بسیاری از بازیکنان مانعی بزرگ محسوب
می‌شد.
معماری رویدادمحور به معنای واکنش به رویدادها برای به‌روزرسانی بی‌درنگ است. در این الگو، سیستم‌ها به‌جای درخواست مداوم داده از یکدیگر، به رویدادها واکنش نشان می‌دهند. این رویکرد برای بازی‌های سرویس‌محور که نیاز به به‌روزرسانی‌های مکرر دارند، بسیار مناسب می‌نماید.
مطابق با وایت‌پیپر متاپلی [۱۰]، فورتنایت از معماری رویدادمحور برای به‌روزرسانی‌های هفتگی بدون توقف استفاده می‌کند، در حالی که آنتم به‌روزرسانی‌های ماهانه با توقف داشت. این تفاوت در رویکرد، یکی از دلایل اصلی ماندگاری فورتنایت در بازار است.
محاسبات بدون سرور به معنای اجرای کد بدون مدیریت سرور است. در این الگو، توسعه‌دهنده کد را اجرا می‌کند و زیرساخت ابری به‌طور خودکار مدیریت می‌شود. این رویکرد برای بک‌اند بازی‌ها بسیار مناسب است، زیرا توسعه‌دهنده نیازی به نگرانی درباره مدیریت سرورها ندارد.
گزارش AWS Lens [۱۱] نشان می‌دهد که فورتنایت از AWS Lambda برای بک‌اند خود استفاده می‌کند، در حالی که آنتم مدیریت دستی سرورها را داشت. این تفاوت در رویکرد، هزینه و پیچیدگی نگهداری آنتم را به‌شدت افزایش داده بود.
بر اساس تحلیل‌های انجام‌شده، پنج الگوی نخست یعنی معماری میکروسرویس، محاسبات لبه، معماری سرور-معتبر، انتقال میزبان و معماری رویدادمحور نقشی حیاتی در موفقیت بازی‌های سرویس‌محور ایفا می‌کنند. دو الگوی دیگر یعنی تحویل هوشمند و محاسبات بدون سرور نیز مهم می‌نمایند اما نه به اندازه پنج الگوی نخست.
نتیجه کلیدی: شکست آنتم یک تصادف نبوده است. این بازی در تمامی هفت الگوی معماری موفق شکست خورده یا ضعیف عمل نموده است. در مقابل، فورتنایت در تمامی هفت الگو به موفقیت دست یافته است.
فورتنایت توسط اپیک گیمز در سال دو هزار و هفده منتشر گردید. با اضافه شدن حالت بتل رویال و انتشار به‌روزرسانی‌های هفتگی، رویدادهای زنده و همکاری با برندهای معروف، این بازی موفق شد پس از هفت سال همچنان در صدر باقی بماند.
معماری این بازی ترکیبی از مدل‌های LR-GaaS و CRA-GaaS است. این بازی از معماری میکروسرویس با AWS Lambda و ECS بهره می‌برد و زیرساخت ابری آن در بیست و شش منطقه AWS مستقر گردیده است. برای کاهش تأخیر، از AWS Global Accelerator استفاده می‌کند و موتور بازی آن آنریل انجین است که به‌صورت ماژولار طراحی شده است.
مدل درآمدیFortnite، رایگان با خریدهای درون‌برنامه‌ای است که شامل بتل‌پس و لوازم آرایشی شخصی‌سازی‌شده می‌شود. مطابق با مقاله [۹]، تجربه «غرق شدن در بازی» و انگیزه «فرار از واقعیت» قوی‌ترین پیش‌بینی‌کننده‌های هزینه در بازی‌های رایگان هستند. فورتنایت با طراحی گیم‌پلی سریع و روان، بارگذاری سریع و رویدادهای مداوم، این دو عامل را به‌خوبی تأمین نموده است.
همچنین، گزارش [۱۷] نشان می‌دهد که شخصی‌سازی شخصیت‌ها با 39 درصد، مهم‌ترین عامل جذب بازیکنان و هزینه در بازی‌های GaaS است. فورتنایت با ارائه هزاران اسکین، ایموت و آیتم شخصی‌سازی‌شده، این نیاز را به‌خوبی برآورده ساخته است.
فورتنایت حدود یکصد و ده میلیون بازیکن ماهانه و حدود پنج و هشت دهم میلیارد دلار درآمد سالانه دارد و در تمام هفت الگوی معماری به موفقیت دست یافته است.
آنتم توسط BioWare در سال 2019 با شش سال توسعه و هزینه بیش از یکصد میلیون دلار منتشر شد. Casey Hudson، مدیر پروژه، بازی را با چشم‌انداز "BioWare جدید" و "یک بازی BioWare با فروش فیفا" به EA فروخت، اما در حین توسعه استعفا داد.
به نقل از مارک دارا: "حتی مشخص نیست که کیسی خودش می‌دانست این به چه معناست. اما حتی اگر هم می‌دانست، او حضور ندارد تا آن عبارت را شفاف‌سازی نماید."
بازی در نهایت با نمره پنجاه و نه از صد در متاکریتیک منتشر گردید. به نقل از مقاله دوبوا [۴]: "محتوای جدید هرگز نتوانست چیزی را که به‌طور گسترده به‌عنوان یک تجربه ضعیف نقد شده بود، نجات دهد." سرورهای آنتم در دوازدهم ژانویه سال دو هزار و بیست و شش خاموش شدند.
معماری فنیAnthem تلاشی ناموفق برای RR-GaaS بود. موتور بازی آن فراست‌بایت بود که موتوری یکپارچه محسوب می‌شود و برای بازی‌های چندنفره بزرگ طراحی نشده است. ساختار سرویس‌های آن شامل سه لایه ناهماهنگ یعنی Blaze، BIGS و Frostbite بود. زیرساخت آن در دیتاسنترهای متمرکز EA قرار داشت و انتقال میزبان در آن پیاده‌سازی نشده بود. حجم بازی نیز بیش از یکصد گیگابایت بود.
گزارش آرس تکنیکا [۱۶] نشان می‌دهد که معماری آنتم به‌شدت وابسته به داده‌های سرور است: "به‌دلیل نحوه طراحی فراست‌بایت، تمام گیم‌پلی در یک بازی فراست‌بایت در بستر 'سرور' اجرا می‌شود."
آنتم در تمام هفت الگوی معماری شکست خورده یا ضعیف عمل نموده است و با نمره پنجاه و نه از صد، یکی از بزرگ‌ترین شکست‌های صنعت بازی محسوب می‌شود.
جدول مقایسه تطبیقی دو بازی موفق و ناموفق به شرح زیر است:
شکست آنتم را می‌توان در سه سطح تحلیل نمود:
سطح نخست: چشم‌انداز و مدیریت
چشم‌انداز آنتم مبهم بود. کیسی هادسون از «آینده داستان‌سرایی» سخن می‌گفت، اما حتی خودش نیز نمی‌دانست این به چه معناست. او در حین توسعه استعفا داد و هدف غیرواقع‌بینانه "یک بازی بیوویر با فروش فیفا" هرگز محقق نشد.
سطح دوم: معماری و فناوری
موتور فراست‌بایت برای بازی‌های تیراندازی اول شخص طراحی شده بود، نه برای بازی‌های چندنفره بزرگ. معماری یکپارچه آن نمی‌توانست از مزایای سرویس‌گرایی بهره‌مند شود. سه سرویس ناهماهنگ Blaze، BIGS و Frostbite به‌درستی با یکدیگر ارتباط برقرار نمی‌کردند و انتقال میزبان در آن پیاده‌سازی نشده بود.
سطح سوم: منابع انسانی و مالی
هفت عضو کلیدی تیم در طول توسعه خارج شدند. فشار کاری بالا در شش سال توسعه، به فرسودگی نیروی انسانی انجامید. پس از شکست بازی، منابع کافی برای تعمیر آن وجود نداشت و هزینه بیش از یکصد میلیون دلاری، بدون بازگشت سرمایه باقی ماند.
برای موفقیت در بازی‌های سرویس‌محور، سه لایه باید به‌درستی طراحی شوند:
لایه نخست: معماری نرم‌افزار-شرط لازم
این لایه شامل هفت الگویی است که در بخش پیشین بررسی شدند. معماری نیکو شرطی لازم برای موفقیت است. فورتنایت در تمام هفت الگو موفق بود و آنتم در هیچ‌یک موفق نبوده‌است.
لایه دوم: عوامل انسانی و مدیریتی - شرط کافی
معماری نیکو به تنهایی کافی نیست. چشم‌انداز مشخص و پایدار، تیم متخصص و با تجربه، مدیریت منابع و بودجه، و مهم‌تر از همه، توجه به بازیکنان از عوامل کلیدی موفقیت هستند.
لایه سوم: مدل کسب‌وکار و درآمدزایی - شرط رشد
مدل درآمدی باید با بازی و بازیکنان هماهنگ باشد. فورتنایت با مدل رایگان و بتل‌پس به موفقیت دست یافت، در حالی که آنتم با مدل پولی و فروشگاه دیرهنگام، نتوانست بازیکنان را جذب نماید.
بر اساس تحلیل بیست منبع معتبر و بررسی تطبیقی فورتنایت و آنتم، یافته‌های زیر به دست آمده است:
۱. هفت الگوی معماری در بازی‌های موفق سرویس‌محور شناسایی شدند: معماری میکروسرویس، محاسبات لبه، معماری سرور-معتبر، انتقال میزبان، تحویل هوشمند، معماری رویدادمحور و محاسبات بدون سرور است.
۲. از میان این هفت الگو، پنج الگوی نخست (میکروسرویس، محاسبات لبه، سرور-معتبر، انتقال میزبان، رویدادمحور) نقشی حیاتی در موفقیت بازی ایفا می‌کنند.
۳. معماری یکپارچه با بازی‌های سرویس‌محور ناسازگار است. آزمایش‌های اولیویرا [۳] نشان داد که معماری توزیع‌شده حدود پنج میلی‌ثانیه سریع‌تر از معماری یکپارچه عمل می‌کند.
۴. محاسبات لبه تأخیر را تا بیست و پنج میلی‌ثانیه کاهش می‌دهد [۷].
۵. انتقال میزبان یک ضرورت فنی برای بازی‌های چندنفره است [۱۵].
۶. تجربه غرق شدن در بازی قوی‌ترین پیش‌بینی‌کننده هزینه بازیکنان است (نسبت شانس ۱.۹۳) [۹].
۷. شخصی‌سازی، مهم‌ترین عامل جذب بازیکنان است (۳۹٪) [۱۷].
۸. مدیریت ضعیف می‌تواند معماری نیکو را نیز شکست دهد [۴].
۹. فورتنایت در تمام هفت الگوی معماری موفق بوده و آنتم در هیچ‌یک موفق نبوده‌است.
۱۰. موفقیت در GaaS نتیجه ترکیبی از معماری درست، مدیریت صحیح، تیم متخصص، مدل درآمدی مناسب و احترام به بازیکنان است.
بر اساس یافته‌های این پژوهش، ده توصیه عملی به توسعه‌دهندگان بازی‌های سرویس‌محور ارائه می‌شود:
از معماری توزیع‌شده (میکروسرویس) استفاده کنید
سرورها را در لبه شبکه قرار دهید.
انتقال میزبان را از روز اول پیاده‌سازی کنید.
معماری سرور-معتبر را طراحی کنید.
متاگیم را همزمان با هسته بازی طراحی کنید.
به‌روزرسانی‌های مداوم با معماری رویدادمحور داشته باشید.
چشم‌انداز مشخص و پایدار داشته باشید.
به بازیکنان گوش دهید و بر اساس بازخورد عمل کنید.
از Pay-to-Win اجتناب کنید.
حجم بازی را با تحویل هوشمند مدیریت کنید.
این پژوهش دارای محدودیت‌هایی است:
تحلیل بر اساس داده‌های ثانویه انجام شده است و امکان بررسی مستقیم کد بازی‌ها وجود نداشت.
ممکن است یافته‌ها به سایر بازی‌های GaaS با ژانرهای متفاوت قابل‌تعمیم نباشند.
برخی منابع صنعتی ممکن است دارای سوگیری تبلیغاتی باشند.
الگوهای معماری ممکن است در ژانرهای مختلف عملکردی متفاوت داشته باشند.
صنعت بازی به‌سرعت در حال تغییر است و یافته‌ها ممکن است در آینده نیاز به بازبینی داشته باشند.
معماری نرم‌افزار، قلب یک بازی سرویس‌محور است؛ اما این قلب بدون اکسیژن مدیریت صحیح، تیم متخصص، مدل درآمدی مناسب و مهم‌تر از همه، احترام به بازیکنان، هرگز نخواهد تپید.
فورتنایت و آنتم هر دو با وعده‌های بزرگ آغاز کردند، اما مسیرهایی متفاوت را پیمودند. فورتنایت با انتخاب‌های درست معماری و مدیریتی، به یکی از پرفروش‌ترین بازی‌های تاریخ با حدود یکصد و ده میلیون بازیکن ماهانه و حدود پنج و هشت دهم میلیارد دلار درآمد سالانه بدل شد. آنتم با انتخاب‌های اشتباه، به یکی از بزرگ‌ترین شکست‌های صنعت بازی با نمره پنجاه و نه از صد در متاکریتیک تبدیل شد و سرورهای آن در دوازدهم ژانویه سال دو هزار و بیست و شش خاموش گردیدند.
از روز نخست به معماری بیندیشید، اما فراموش نکنید که معماری به تنهایی کافی نیست. موفقیت در بازی‌های سرویس‌محور نتیجه ترکیبی از معماری درست، مدیریت صحیح، تیم متخصص، مدل درآمدی مناسب و مهم‌تر از همه، احترام به بازیکنان است.
GaaS مدل ارائه بازی به‌عنوان سرویس مداوم
RR-GaaS رندرینگ از راه دور - رندرینگ ویدیو در ابر
LR-GaaS رندرینگ محلی - رندرینگ در دستگاه کاربر
CRA-GaaS تخصیص پویای مؤلفه‌ها - جابجایی پویا بین ابر و کلاینت
Microservices معماری مبتنی بر سرویس‌های مستقل
Edge Computing محاسبات در لبه شبکه، نزدیک به کاربران
Server-Authoritative اعتبارسنجی همه اقدامات در سمت سرور
Host Migration انتقال میزبان به سرور دیگر در صورت قطعی
Intelligent Delivery مدیریت حجم بازی با نصب انتخابی بخش‌ها
Event-Driven Architecture معماری مبتنی بر رویدادها
Serverless Computing اجرای کد بدون مدیریت سرور
Battle Pass سیستم پاداش‌های فصلی در بازی‌های رایگان
F2P بازی رایگان با خریدهای درون‌برنامه‌ای
Meta-Game لایه فرابازی شامل پیشرفت، فروشگاه، بتل‌پس
LiveOps عملیات زنده شامل رویدادها و به‌روزرسانی‌ها
Monolithic معماری یکپارچه
Frostbite موتور بازی یکپارچه EA
Unreal Engine موتور بازی ماژولار Epic Games
AWS Amazon Web Services - زیرساخت ابری
Flow حالت غرق شدن کامل در بازی
[1] W. Cai, M. Chen, and V. C. M. Leung, "Toward Gaming as a Service," IEEE Internet Computing, pp. 12-18, 2014.
[2] P. Amini, S. A. Z. Motlagh, and M. Nezhadpour, "A Large-Scale Infrastructure for Serious Games Services," in 2nd Digital Games Research Conference (DGRC), 2018.
[3] S. S. de Oliveira, C. H. R. Souza, J. C. Silva, and S. T. Carvalho, "Towards Scalable Cloud Gaming Systems: Decoupling Physics from the Game Engine," in 22nd Brazilian Symposium on Games and Digital Entertainment (SBGames), 2023, pp. 1-10.
[4] L. É. Dubois and A. Chalk, "Service Withdrawal: The Uncertain Future of the Games-as-a-Service Model," Convergence, pp. 479-499, 2025.
[5] S. A. Hamid, Y. Boujelben, and F. Zarai, "Enhancing Cloud Gaming Experience through Optimized Virtual Machine Placement: A Comprehensive Review," Journal of Network and Systems Management, pp. 1-31, 2024.
[6] T. Ishioka, T. Fukui, T. Fujiwara, S. Narikawa, T. Fujihashi, S. Saruwatari, and T. Watanabe, "Traffic Reduction for Speculative Video Transmission in Cloud Gaming Systems," IEICE Transactions on Communications, pp. 408-418, 2024.
[7] D. Olliaro, V. Mancuso, P. Castagno, M. Sereno, and M. Ajmone Marsan, "Performance of Distributed Multiparty Online Gaming over Edge Computing Platforms," Computer Communications, pp. 1-14, 2026.
[8] K. Rasol, A. Egio, M. Catalan-Cid, L. Lossi, H. Simeão, and S. Siddiqui, "5GaaS: DLT and Smart Contract-Based Network Slice Management in a Decentralized Marketplace," in 20th International Conference on Network and Service Management (CNSM), 2024, pp. 1-7.
[9] J. M. Costes and C. Bonnaire, "Spending Money in Free-to-Play Games: Sociodemographic Characteristics, Motives, Impulsivity and Internet Gaming Disorder Specificities," International Journal of Environmental Research and Public Health, pp. 1-14, 2022.
[10] Metaplay and Photon, "How to Build a Multiplayer Live Service Game in 2026," Industry Whitepaper, 36 pages, 2026.
[11] A. Hatfield, "Games Industry Lens Update for the Well-Architected Framework," AWS Blog, Dec. 10, 2025.
[12] AccelByte, "AccelByte Gaming Services (AGS) - Technical Overview," Technical Documentation, Jan. 21, 2026.
[13] S. Poueme and A. Hatfield, "Modernize Game Backend Services with AWS Global Accelerator," AWS for Games Blog, Dec. 18, 2024.
[14] O. Kuhnke, "Former BioWare Producer Details What Went Wrong With Anthem," GameSpot, Aug. 6, 2025.
[15] O. Kuhnke, "As Anthem Approaches Its Shutdown, Ex-BioWare Boss Reflects," GameSpot, Aug. 20, 2025.
[16] K. Orland, "Why Reviving the Shuttered Anthem Is Turning Out Tougher Than Expected," Ars Technica, Jan. 28, 2026.
[17] R. Gokhale, P. R. Peddareddy, N. Robinson, P. Shireman, and A. Whitehurst, "How Games as a Service (GaaS) and Transmedia Strategies Sustain Video Game Franchises, Part II," Carnegie Mellon University Report, Feb. 11, 2026.
[18] EPAM Systems, "Gaming as a Service: Redefining the Way We Play," Industry Whitepaper, 2025.
[19] Microsoft, "Supporting Games-as-a-Service (GaaS) - Microsoft Game Development Kit," Technical Documentation, 2025.
«اين مطلب، بخشي از تمرينهاي درس معماري نرم‌افزار در دانشگاه شهيدبهشتي است»
