معماری نرم‌افزار در توسعه نرم‌افزار بازی

چکیده

توسعه دهندگان بازی هر سال با تقاضای فزاینده برای بازی‌های جدید مواجه هستند. فرایند توسعه بازی به دلیل پیچیدگی پلتفرم بازی و عدم وجود متدلوژی‌های توسعه بازی برای فرایندهای یکپارچه‌سازی دشوار است. امروزه برخی از پروژه‌های بازی بسیار پیچیده هستند و پلتفرم‌ها و برنامه‌های نرم‌افزاری که آن‌ها را هدایت می‌کنند به نسبت پیچیده‌تر می‌شوند.که به سبب آن نرم‌افزار بازی دارای معماری نرم‌افزار پیچیده با ماژول‌های فراوان متصل به هم است. در نتیجه تیم‌های توسعه‌دهنده بازی بزرگتر می‌شوند و نقش افراد در این تیم‌ها تخصصی‌تر می‌شود. برای ایجاد یک بازی و مکانیک‌های موجود در آن با کیفیت بالا و هزینه و زمان کمتر باید اصول مهندسی و معماری نرم‌افزار رعایت شود. معماری نرم‌افزار می‌تواند به عنوان نقطه شروعی برای توسعه یکپارچه بازی باشد و به عنوان بخش مهمی از فرایند طراحی و توسعه بازی است که سبب دستیابی به نرم‌افزاری با عملکرد خوب و قابلیت تغییرپذیری و انعطاف بالا می‌گردد. امروزه توسعه‌دهندگان نرم‌افزار به دنبال یافتن معماری نرم‌افزاری هستند که امکان استفاده مجدد، انتقال و توسعه را فراهم کند. بنابراین این مقاله مروری به مرور، بررسی و مقایسه رویکردهای موجود در معماری نرم‌افزار برای طراحی و توسعه انواع بازی‌ها به منظور دستیابی به ویژگی‌های کیفی و یکپارچه‌سازی برنامه‌های بازی و کاهش هزینه، زمان و پیچیدگی می‌پردازد و سپس پیشنهاداتی به منظور بهبود طراحی و توسعه نرم‌افزارهای بازی در حوزه معماری نرم‌افزار ارائه می‌گردد.

۱. مقدمه

توصیف مؤلفه‌های اصلی و ساختارهای مهم یک سیستم نرم‌افزاری به همراه توصیف ارتباطات و تعاملاتی که بخش‌های مختلف با یکدیگر دارند را معماری نرم‌افزار می‌گویند که توصیفی سطح بالا از نرم‌افزار است. معماری نرم‌افزار درک مشترک افراد از سیستم و تصمیم‌های طراحی زودهنگام در نرم‌افزار است. هدف معماری نرم‌افزار کمینه کردن منابع انسانی مورد نیاز برای ساخت و نگهداری سیستم مورد نظر است. بازی نیز یک برنامه نرم‌افزاری است و توسعه آن دارای چالش‌ها و مشکلاتی است و با افزایش زمان، هزینه و ویچیدگی همراه است. بنابراین برای طراحی، توسعه و یکپارچه‌سازی آن به منظور دستیابی که ویژگی‌های کیفی از جمله قابلیت استفاده مجدد، قابلیت همکاری، انعطاف‌پذیری، توسعه‌پذیری، قابلیت نگهداری، استحکام، مقیاس‌پذیری، قابلیت اعتماد، قابلیت حمل و ... از رویکردهای موجود در معماری نرم‌افزار استفاده می‌شود.

از جمله روش‌های موجود استفاده از رویکرد مدل محور است. سبب افزایش سطح انتزاع در توسعه بازی می‌شود. ترکیبی از زبان‌های خاص دامنه (DLS) تولید‌کننده کد است. از مدل‌هایی برای تعریف مشخصات دامنه‌های مختلف استفاده می‌کند که به عنوان ورودی برای مجموعه‌ای از تبدیل‌ها که به طور خودکار کد را تولید می‌کنند می‌باشد. همچنین سبب می‌شود تا توسعه‌دهندگان کم‌تجربه‌تر با شرکت در فرایند ایجاد بازی برخی از مسائل موجود در صنعت را حل کنند [2]. این رویکرد دارای چسبندگی ضعیف هست که امکان تعویض فناوری‌های اصلی را فراهم می‌کند و به توسعه‌دهندگان این امکان را می‌دهد تا مؤلفه‌های اولویت‌دار را به صورت منعطف برای پشتیبانی از سبک خاصی از بازی جدی انتخاب کنند و بهره‌وری و قابلیت استفاده مجدد از مصنوعات نرم‌افزاری افزایش می‌یابد در نتیجه زمان توسعه کاهش می‌یابد و قابلیت همکاری و قابلیت حل بین پلتفرم‌های بازی افزایش می‌یابد [3][4].

روش دیگر استفاده از الگوهای طراحی و معماری است. الگوهای طراحی یک راه‌حل کلی قابل استفاده مجدد در مسائل تکرارشونده و زمینه قابل استفاده مجدد است که مستقیما به کد قابل تبدیل نیستند و در داخل هر پروژه، الگوها به کد تبدیل می‌شوند. الگوهای طراحی راه‌حل‌های ثابت شده‌ای برای مشکلات مهندسی نرم‌افزار هستند و در برنامه‌نویسی بازی سبب اطمینان یافتن از صحت برنامه توسط ارزیابی رفتار کاراکتر ، مقیاس‌پذیری، نگهداری، انعطاف‌پذیری، توسعه‌پذیری، کاهش هزینه نگهداری و استحکام در برابر تغییرات می‌گردد [11]. الگوهای معماری همانند الگوهای نرم‌افزاری هستند ولی در سطح معماری نرم‌افزار قرار دارند و روش‌های طراحی برای معماری نرم‌افزار در ابعاد گسترده‌تری هستند. خط تولید نرم‌افزار مجموعه‌ای از سیستم‌های نرم‌افزاری است که دارای مجموعه‌ای از ویژگی‌های عمومی و مدیریت شده مشترک هستند، نیازهای مشخصی از بازار یا ماموریت خاصی را برآورده می‌نمایند و براساس مجموعة مشترکی از دارایی‌های اصلی توسعه داده می‌شوند. از بین دارایی‌های اصلی یک خط تولید نرم‌افزار، معماری مهم‌ترین دارایی است که محصولات متعلق به خط تولید نرم‌افزار را تعریف می‌کند و به تشخیص صحیح عناصر ثابت و نقاط تغییر برای همه اعضای خط تولید نرم‌افزار می‌پردازد.

در این مقاله ابتدا به مرور و بررسی کارهای پیشین در حوزه استفاده از معماری نرم‌افزار در توسعه نرم‌افزار بازی با استفاده از رویکردهای مدل محور، الگوهای طراحی و معماری، سایر رویکردهای موجود در حوزه معماری نرم‌افزار و خط تولید نرم‌افزار به منظور بهبود توسعه، طراحی و یکپارچه‌سازی انواع بازی‌ها، دستیابی به ویژگی‌های کیفی، کاهش زمان، هزینه و پیچیدگی و ... در برنامه‌های بازی پرداخته می‌شود. سپس تحلیل و ارزیابی رویکردهای پیشین و مقایسه و بررسی آن‌ها براساس ویژگی‌هایی بیان می‌گردد. در پایان نیز پیشنهاداتی برای بهبود طراحی و توسعه نرم‌افزار بازی در حوزه معماری نرم‌افزار ارائه می‌گردد.

۲. کارهای پیشین

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

• حوزه مدل‌محور

در این بخش به مرور و بررسی کارهای پیشین در حوزه مدل‌محور در توسعه نرم‌افزار بازی پرداخته می‌شود.

۲.۱. توسعه مدل محور رابط کاربری برای بازی‌های آموزشی [1]

هدف این معماری مدلسازی و توسعه رابط کاربری بازی‌های آموزشی و طراحی رابط کاربری برای دادن انگیزه به کاربران با توانایی یادگیری و اولویت‌های متنوع در فرایند یادگیری است است که براساس مدل و چارچوبی شامل فرا مدل‌ها، مدل‌ها،‌ تبدیل‌ها و ابزارهای نرم‌افزاری است و با شناسایی پروفایل‌های بازیکن براساس توانایی‌ها و اولویت‌های بازیکن و اتخاذ تعامل بازی با پروفایل بازیکن به دست می‌آید. این معماری شامل اصول تئوری انگیزشی و همچنین تعامل انسان و کامپیوتر چند وجهی است. مدلسازی این رویکرد با استفاده از UML و XML و ادغام مکانیزم‌ها صورت می‌گیرد و مؤلفه‌ها براساس زبان استاندارد و رایج تعریف شده در متامدل بازی آموزشی است. مزیت آن قابلیت استفاده مجدد از دانش و همچنین محتوای بازی است یعنی توانایی نگهداری تعامل بازی، در حالی که فقط محتوای آموزشی تغییر می‌کند.

در شکل 1 مفهوم ارتباط بین بازیکن و بازی نمایش داده شده است. مفهوم اصلی در این فرامدل، GameModality است که به عنوان نوعی تعامل بین بازیکن و بازی تعریف شده است و از فرامدل چندمدلی تعامل انسان – کامپیوتر ایجاد می‌شود. تعامل چندمدلی را می‌توان بین چند بازیکن و (GamePlayer) و چندین پلتفرم بازی (GamePlatform) برقرار کرد. GameContext مجموعه‌ای از شرایط و حقایق مربوط به وضعیتی خاص را تعریف می‌کند و می‌تواند بر تعامل بین انسان و بازی تاثیر بگذارد. طبقه‌بندی GameContext شامل زمینه فیزیکی برای بین شرایط محیطی، زمینه موقعیتی برای بیان وضعیت فعلی در محیط از نقطه نظر وظیفه کاربر، دانش مشترک یعنی مجموعه‌ای از حقایق درک شده توسط انسان و کامپیوتر و زمینه اجتماعی برای بیان محیط اجتماعی تعامل است.

در شکل 2 جزئیات ارتباط بین بازیکن و بازی نمایش داده شده است. مؤلفه Input Output EduGameInteraction مربوط به ورودی کاربر و Output EduGameInteraction مربوط به خروجی بازی است. EduGameEngine تمام عناصر یک صحنه را در بازی ایجاد می‌کند. PlayerProfile در ابتدای بازی تشخیص داده می‌شود و می‌تواند به صورت پویا در طول بازی تنظیم شود و به اقدامات بازیکن وابسته است. مؤلفه UserInterfaceAction اقدامات سطح پایین انجام شده توسط بازیکن مانند حرکت ماوس یا فشردن کلید صفحه کلید را نمایش می‌دهد. EduGameInteraction اقدامات را مدیریت می‌کند و تغییراتی که بر EduGame اثر می‌گذارد را تشخیص می‌دهد. زمانی که یک اقدام مهم شناسایی می‌شود، EduGameEvent افزایش می‌یابد مثل پاسخ به یک سوال یا حل یک پازل و سپس به EduGameEngine برای پردازش‌های بیشتر ارسال می‌شود. EduGameEngine یک EduGameScen جدید تولید می‌کند و Output EduGameInteraction را راه‌اندازی می‌کند. هدف اصلی جداسازی EduGameEngine و EduGameInteraction است. EduGameEngine منطق بازی را نمایش می‌دهد و EduGameInteraction نمایانگر تعامل با بازیکن است.

۲.۲ یک رویکرد توسعه بازی مدل محور منعطف [2]

از یک رویکرد توسعه بازی مدل‌محور (MDGD) که ترکیبی از چندین زبان خاص دامنه (DSL) با الگوهایی برای ایجاد انعطاف‌پذیری، بهره‌وری، تسهیل و توسعه استفاده شده است و یک موتور بازی، چند DSL، تولید کد و الگوهای طراحی سبب ادغام کد تولید شده با کد دستی ادغام می‌شود که نتیجه آن یک موتور بازی با مزایای MDGD بدون از دست دادن انعطاف‌پذیری است. توسعه‌دهندگان با تجربه کمتر نیز می‌توانند بازی‌ها را سریع‌تر و آسان‌تر با موتور بازی ایجاد کنند و انعطاف‌پذیری را برای توسعه‌دهندگان فراهم می‌کند. با استفاده از MDGD توسعه‌دهندگان با کد نهایی کمتر آشنا می‌شود و کدنویسی دستی را سخت‌تر می‌کند.

شکل 3 نمای کلی رویکرد را نمایش می‌دهد که در آن سه ویرایشگر دوربین، کاراکتر و سناریو توسعه داده شده است. توسعه‌دهنده ممکن است مدل‌هایی برای این ویژگی‌ها ایجاد کند که این مدل‌ها در فایل‌های XML ذخیره می‌شوند. یک پردازنده الگو مدل‌ها را می‌خواند و براساس برخی از قالب‌های توسعه‌یافته کدی تولید می‌شود که جنبه‌های مدلسازی شده را پیاده‌سازی می‌کند. کد تولید شده با معماری بازی مرجع از طریق برخی از الگوهای طراحی ادغام می‌شود. این الگوها امکان ادغام کدهای تولید شده و تولید نشده را فراهم می‌کنند. در نتیجه بازی روی یک موتور بازی اجرا می‌شود و حداکثر انعطاف‌پذیری و پتانسیل را برای بازی ارائه می‌دهد.

برای نمایش معماری، از یک نمودار UML برای نمایش اشیای بازی و ساختار ایستا استفاده می‌شود. این معماری برای تولیدکنندگان کد مختلف امکان همکاری و پشتیبانی از ادغام با کد دستی را فراهم می‌کند که در شکل 4 نمایش داده شده است. در آن یک کلاس اصلی وجود دارد که نمایانگر نقطه ورود به توسعه بازی‌ها در موتور بازی است، این کلاس دارای متدهایی برای مقداردهی اولیه است و تعدادی ویژگی و متد برای تغییرات حالت داخلی دارد. کلاس اصلی همچنین با سایر کلاس‌ها برای نمایش عناصر اصلی یک بازی ارتباط دارد. برای هر زیردامنه یک بسته وجود دارد. بسته دوربین شامل یک interface و یک کلاس پیاده‌سازی است که مسئول پیکربندی دوربین است. بسته کاراکتر شامل یک interface و یک کلاس پیاده‌سازی است که مسئول تغییرات و پیکربندی کاراکتر است. بسته سناریو شامل یک interface و 4 کلاس شامل کلاس سناریو بازی به عنوان ظرفی برای عناصر سناریو، کلاس کف و بستر سناریو، کلاسی برای تشخیص موقعیت اولیه کاراکترها و کلاسی برای تشخیص موقعیت اولیه بازیکن است. سناریو همچنین شامل مجموعه‌ای از بخش‌ها برای نمایش برخی از عناصر هست. برخی از بخش‌های معماری به صورت دستی و برخی دیگر به صورت خودکار انجام می‌شود.

این رویکرد برای ادغام کد دستی و کد تولید شده از الگوهای طراحی را با توجه به موقعیت استفاده می‌کند. در موقعیتی که کد تولید شده به کد تولید نشده بستگی داشته باشد، از الگوی Facade استفاده می‌شود که برای سهولت تعامل بین کد تولیدشده و کد تولید نشده استفاده می‌شود. در موقعیتی که کد تولید نشده وابسته به کد تولید شده است، می‌توان از الگوی Factory استفاده کرد. در موقعیتی که کد تولید شده به کد تولید شده وابستگی دارد، دو تا زیردامنه باید به هم ارجاع دهند که یک راه استفاده از نام عناصر به عنوان ارجاعات است که باید با نام عناصر ارجاع شده در مدل دیگر تطبیق داده شود. راه دیگر، پل‌های مدل است که ایجاد تکراری عناصر از فرامدل ارجاع شده به متامدل مرجع است. این معماری ادغام بین چند DSL را سبب می‌شود. همچنین امکان درج کد سفارشی را فراهم می‌کند. با استفاده از رویکرد MDGD وظایف با نرخ بیشتری به درستی انجام می‌شود.

۲.۳ یک مدل فناوری بازی مستقل از پلتفرم برای توسعه بازی‌های جدی مدل محور [3]

مدل فناوری بازی (GTM) یک نمایش محاسباتی نرم‌افزار بازی و مستقل از پلتفرم پیاده‌سازی و سخت‌افزار مبتنی بر مدل محتوای بازی و معماری داده‌محور برای رفع ضعف ابزارهای نویسندگی سطح بالا برای بازی‌های جدی برای متخصصان غیردامنه ارائه شده است که مدل‌های نرم‌افزاری بازی جدی را مستقل از هر سخت‌افزار یا مشخصات پلتفرم برای استفاده در توسعه بازی جدی مدل محور ایجاد می‌کند. با استفاده از ابزار مهندسی مدل‌محور (MDE) مدل محتوای بازی به مدل فناوری بازی ترجمه می‌شود. در این معماری از مدل‌ها و ابزار MDE برای نمایش محتوا و منطق در تولید مصنوعات نرم‌افزاری استفاده می‌شوند. دسترس‌پذیری GTM و ابزارهای نویسندگی سطح بالا امکان تست و ارزیابی را برای نمونه اولیه فراهم می‌کند و بهبود بیشتری در طراحی بازی‌ بدون داشتن موانع فنی موجود در توسعه بازی‌های جدی آموزشی ایجاد می‌کند.

براساس شکل 5 فناوری بازی در این رویکرد دارای دو لایه اصلی یعنی لایه سیستم‌های خاص بازی لایه مؤلفه‌های اصلی است. لایه سیستم‌های خاص بازی از سیستم زمینه بازی تشکیل شده است که بازی را تنظیم می‌کند و تعویض پویا بین presentation و شبیه‌سازی را مدیریت می‌کند. سیستم شبیه‌سازی بازی شامل اشیا بازی ایستا و پویا است و ‌رویدادهای بازی را تشکیل می‌دهد. لایه مؤلفه‌های اصلی انعطاف‌پذیری را برای تعیین مؤلفه‌های ارجح‌تر و افزایش استقلال روی انتخاب فناوری‌های بازی را فراهم می‌کند. از امکانات لایه اصلی برای فعال‌سازی اجرای سیستم محتوای بازی و سیستم شبیه‌سازی بازی استفاده می‌کند. رابط کاربری، پخش‌کننده ویدیو، فیزیک‌های بازی، انیمیشن، گرافیک، صدا، هوش مصنوعی، ورودی، شبکه و مدیریت منابع بازی به عنوان فناوری‌های اصلی در لایه مؤلفه اصلی مدل فناوری بازی هستند. شبکه به عنوان یک مؤلفه سرویس در نظر گرفته می‌شود که توسعه‌دهندگان در هنگام توسعه بازی‌های چند نفره از آن استفاده کنند. در GTM همه داده‌های شبکه به عنوان جریان‌های ورودی توسط کنترل‌کننده پیام مدیریت می‌شوند.

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

۲.۴ خودکارسازی prototype در توسعه بازی مدل محور [4]

رویکردی برای خودکارسازی نمونه اولیه بازی دو بعدی از طریق استفاده از مهندسی مدل محور (MDE) ارائه شده است که نتایج رضایت‌بخشی را برای تولید کد نشان می‌دهد، سبب افزایش سطح انتزاع توسعه بازی نسبت به مدلسازی مفهومی، افزایش معنادار بهره‌وری و کاهش زمان و هزینه توسعه، امکان استفاده مجدد برای تکامل نهایی می‌گردد. مدل‌های مستقل از پلتفرم (PIM) ساختار و رفتار بازی و یک مدل پلتفرم خاص (PSM) نگاشت کنترل بازی را فراهم می‌کند. نمونه اولیه حاصل می‌تواند برای تکامل بازی نهایی دوباره مورد استفاده قرار گیرد. برنامه‌نویس باید فقط جنبه‌های تعریف نشده در مدل مانند هوش مصنوعی دشمنان را کدنویسی کند. همچنین برای تسهیل ایجاد موجودیت‌های بازی یک ویرایشگر سطح گرافیکی توسعه داده شده است. در شکل 6 نمایی از این رویکرد نمایش داده شده است.

ویرایشگرها سبب تسهیل مدلسازی با استفاده از یک رابط کاربری مناسب می‌شود. براساس شکل 7 یک یا چند مدل پلتفرم خاص (PSM) نحوه پیاده‌سازی (PIM) در هر پلتفرم میان‌افزار را توصیف می‌کند. تبدیل مدل PIM به مدل‌های PSM قبل از تولید کد سبب جداسازی سطوح عملکرد و فناوری می‌شود که تطبیق مداوم با پلتفرم‌های فناوری جدید را تسهیل می‌کند. در این رویکرد از زبان خاص دامنه گرافیکی (DSL) برای نمایش جنبه‌های مختلف بازی استفاده می‌شود. با نگاشت کنترلی می‌توان رفتار بازی را از کنترل‌کننده با استفاده از تعامل با بازی جدا کرد که بازیکنان می‌توانند با بازی از طریق کنترل‌کننده‌ها یا نگاشت‌های مختلف تعامل کنند و پاسخ‌دهی به صورت یکپارچه صورت می‌گیرد. به دلیل آن که نمودار نگاشت کنترلی یک عمل بازی را به یک سیگنال کنترلی ارسال شده از یک کنترلر مرتبط می‌کند، نگاشت کنترلی می‌تواند سیگنال‌های کنترلی را به اقدامات بازی ترجمه کند.

۲.۵ طراحی بازی MDA برای توسعه بازی ویدیویی توسط سبک [5]

روشی نیمه خودکار برای توسعه انواع مختلف بازی‌های arcade با استفاده از معماری مدل محور برای توسعه‌دهندگان مبتدی است و هدف این رویکرد تست فوری برنامه‌ها پس از نوشتن آن‌ها است. همچنین یک فرامدل را برای طراحی بازی فراهم می‌کند که مشخصاتی را برای یک انتزاع سطح بالا و مستقل از پلتفرم ایجاد می‌کند. امکان تولید یک بازی دو بعدی را از ویژگی‌های اساسی تولیدکننده این نوع بازی ویدیویی فراهم می‌کند. همچنین مجموعه‌ای از قوانین تبدیل مدل برای تولید کد جاوا قابل اجرا از یک مدل خاص و روشی استاندارد برای طراحان مبتدی بازی را فراهم می‌کند و کارایی و اثربخشی توسعه‌دهندگان را به حداکثر می‌رساند. در شکل 8 نمایی از این رویکرد نمایش داده شده است.

پلتفرم مورد استفاده در این بازی به توسعه‌دهندگان اجازه می‌دهد که کد خود را یکبار بنویسند اما آن را روی منابع مختلف و برای هر سبکی اجرا کنند. MDA فرایند مبتنی بر مجموعه‌ای از مدل‌ها را برای ساختار نرم‌افزار ارائه می‌دهد و راهی جدید برای توسعه نرم‌افزار با تبدیل یک مدل ورودی به یک مدل خروجی است. این مدل‌ها در سه راستا شامل مدل مستقل محاسباتی (CIM) برای توصیف سیستم بدون نمایش جزئیات ساخت آن، مدل مستقل از پلتفرم (PIM) برای انعکاس عملکردها، ساختار و رفتار یک سیستم بدون اطلاعاتی از پلتفرم یا فناوری مورد استفاده و مدل پیاده‌سازی گرا و خاص پلتفرم (PSM) مطابق با اولین مرحله اتصال یک PIM مشخص به یک پلتفرم اجرایی مشخص سازماندهی می‌شود. با استفاده از برخی قوانین تبدیلات مدل، سیستم نرم‌افزاری از یک PIM به کد منبع توسعه می‌یابد. در توسعه این رویکرد در مرحله اول، PIM برای انواع بازی‌های arcade تعریف می‌شود. در مرحله دوم یک نمونه از PIM ایجاد می‌شود. در مرحله سوم مجموعه‌ای از قوانین تبدیل مدل به متن، کد منبع را از مدل arcade تولید می‌کند.

۲.۶ رویکرد MDA برای قابلیت استفاده مجدد در بازی جدی و طراحی آموزش الکترونیکی [6]

هدف این رویکرد کاهش زمان و هزینه توسعه سناریوهای بازی‌های جدی با ارائه فرایندی برای ساخت سناریوهای عمومی با قابلیت استفاده مجدد و قابلیت همکاری مبتنی بر معماری مدل محور است برای این منظور یک متامدل که قابلیت توصیف و شاخص‌گذاری سناریوهای بازی را دارد استفاده می‌شود. سپس از رویکرد MDA برای تولید، ترجمه، تعویض و بروزرسانی این سناریوها و ادغام آن‌ها در پلتفرم‌های مختلف استفاده می‌شود. سناریوهای پیچیده‌تر نیاز به قوانین پیچیده‌تری برای انطباق مدل‌های تولید شده با فرامدل پایه دارند. از ویرایشگر گرافیکی برای طراحی سناریوهای ساده استفاده می‌شود. سپس غنی‌سازی مرحله به مرحله سناریو با طراحی و گنجاندن سایر مؤلفه‌های بازی صورت می‌گیرد. پیاده‌سازی سناریوهای بازی آموزشی و ادغام آن‌ها در دو زمینه ارائه می‌شود. اولین زمینه بر جنبه‌های بازی تمرکز می‌کند و دومین زمینه بر جنبه‌های آموزشی تمرکز می‌کند. در شکل 9 نمایی از این رویکرد نمایش داده شده است.

در این رویکرد گام اول شامل تعریف یک مدل محاسباتی مستقل (CIM) است. مرحله دوم تبدیل مدل CIM به یک مدل مستقل پلتفرم (PIM) است. در نهایت MDA، مدل PIM را به مدل دیگری (PSM) طراحی شده برای نمایش یک پلتفرم خاص تبدیل می‌کند. بنابراین طراح بازی می‌تواند مدل‌های آموزشی و لذت‌بخش را در سطح PIM مطابق با مفهوم متامدل در مرحله CIM‌ طراحی کند. مدل PSM قابلیت توصیف مشخصات پلتفرم را دارد، به محتوای عملیاتی بستگی دارد، یک پلتفرم هدف را نمایش می‌دهد و جزئیات سناریو و ویژگی‌های گرافیکی در سطح PSM ارائه می‌شوند که این جزئیات می‌تواند مشخصات شی بازی را نمایش دهد. گام بعدی ادغام مؤثر عناصر PSM در پلتفرم هدف است. MDA به مدل‌های انتزاعی متکی است که استقلال آن را از هر سیستم سخت‌افزاری یا نرم‌افزاری ارتقا می‌دهد. در این رویکرد فرامدل باید شامل محتوای بازی باشد. به منظور حفظ انعطاف‌پذیری باید جنبه آموزشی و بازی جداگانه و هم‌زمان تعریف شوند.

• حوزه الگوهای طراحی و معماری

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

۲.۷. یک معماری نرم‌افزار مشترک برای بازی‌های آموزشی (EGA) [7]

یک معماری نرم‌افزار مشترک برای همه بازی‌های آموزشی (EGA) ارائه شده است که دستورات معماری را به صورت یکپارچه و رسمی تحقق می‌بخشد و می‌تواند به عنوان طرحی برای بهبود بهره‌وری و کیفیت بازی‌های آموزشی مورد استفاده قرار گیرد. EGA می‌تواند به عنوان یک الگوی طراحی، مجددا استفاده قرار گیرد و دارای دو مزیت اصلی است. اول این که طراحان بازی‌ نیازی به کشف و اختراع مجدد ساختار، ارتباطات و مؤلفه‌های مشترک بازی آموزشی ندارد که سبب افزایش بهره‌وری می‌گردد. دوم این که EGA همه ویژگی‌های عملکردی لازم برای اثربخشی بازی‌های آموزشی موفق با احتمال بالا را فراهم می‌کند. EGA یک انتزاع سطح بالا از بازی‌های آموزشی ارائه می‌دهد و در مورد جزئیات پیاده‌سازی نیست و مستقل از پلتفرم و موتور بازی است.

معماری EGA شامل 4 زیرسیستم است. اول موضوع است که بازنمایی موضوعات یادگیری توسط عناصر بازی مناسب است. کل موضوعات یادگیری باید ابتدا به گروهی از واحد‌های دانش شکسته شوند و توسط عناصر بازی نمایش داده شوند. شی بازی یک واحد دانش را نمایش می‌دهد که Metaphor نامیده می‌شود. بنابراین زیرسیستم شی گروهی از Metaphorها است. یک بازی می‌تواند ترکیبی از چند سبک باشد. هر سبک به معنای گروهی از عناصر بازی است که برای رسیدن به یک هدف با یکدیگر همکاری می‌کنند. بنابراین زیرسیستم موضوع شامل چندین سبک است که هر سبک گروهی از Metaphorها است. دوم، وظایف یعنی اختصاص دادن وظایف مناسب، خاص، روشن و مرتبط برای بازیکنان براساس عملکرد آن‌ها است. سوم، فعالیت‌ها یعنی ارائه ابزار تعاملی برای بازیکنان به منظور تعامل آن‌ها با آن چه یاد می‌گیرند، است و این مؤلفه شامل گروهی از زیرسیستم‌های ورودی به نام فعالیت است. چهارم، بازخوردها یعنی دادن بازخورد به بازیکنان در مورد عملکردشان است. براساس شکل 10 قهرمان بازی از فعالیت برای تعامل با موضوع استفاده می‌کند که انجام برخی کارها بر موضوع تاثیر می‌گذارد. در نتیجه موضوع از مؤلفه بازخورد برای دادن تعدادی بازخورد استفاده می‌کند که بر قهرمان تاثیر می‌گذارد.

معماری EGA می‌تواند دوباره برای ایجاد معماری بازی Sim-Eduventure استفاده شود اما باید ابتدا تطبیق یا گسترش یابد. تطبیق EGA برای یک مورد خاص بسیار آسان است. در این معماری حداقل دو زیر سیستم موضوع و وظایف باید گسترش داده شوند و دو زیرسیستم دیگر یعنی بازخوردها و فعالیت‌ها ثابت می‌مانند. هر Metaphor در Sim-Eduventure مسئولیت وظیفه شبیه‌سازی مشابهی را در سیستم هدف به عهده دارد. به دلیل داشتن ماهیت تودرتو ممکن است یک Metaphor جزئی از Metaphor دیگر باشد. همه Metaphorها با یکدیگر کل سیستم هدف را شبیه‌سازی می‌کنند.

۲.۸. معماری RAGE برای استفاده مجدد مؤلفه‌های فناوری بازی جدی [8]

یک معماری کلی برای تسهیل ادغام و قابلیت استفاده مجدد دارایی‌های نرم‌افزار برای پلتفرم بازی است و از قابلیت استفاده مجدد مؤلفه‌های بازی جدی در زبان‌های برنامه‌نویسی، موتورهای بازی و پلتفرم‌های مختلف بازی پشتیبانی می‌کند. این معماری برای قابلیت حمل دارایی‌ها در سیستم‌ها، زبان‌های برنامه‌نویسی و موتورهای بازی مختلف مورد استفاده قرار می‌گیرد و سبب توسعه در مقیاس بزرگ و برنامه‌های چند موتوره می‌شود.از وابستگی به چارچوب‌های نرم‌افزاری خارجی جلوگیری می‌کند. کدهایی که با کد موتور بازی ادغام نمی‌شوند را به حداقل می‌رساند. به مجموعه محدودی از الگوهای استاندارد نرم‌افزاری متکی است. هدف این معماری تقویت انسجام داخلی و پتانسیل بازی‌های جدی برای آموزش، یادگیری و سایر حوزه‌ها است. در این معماری ساختار و عملکرد دارایی‌های سمت کلاینت مورد توجه قرار می‌گیرد.

یک دارایی یک رابط کاربری استاندارد ارائه می‌دهد که می‌تواند مستقیما توسط یک موتور بازی یا الگوی پل پیاده‌سازی شود. دارایی‌ها باید شامل یک سیستم منسجم و مبتنی بر مؤلفه باشند که از قابلیت همکاری داده بین عناصر پشتیبانی می‌کند. دارایی حاوی یک فایل کد منبع یا یک فایل برنامه کامپایل شده یا ممکن است شامل مصنوعات دیگر باشد. دارایی‌های RAGE به عنوان مؤلفه‌های نرم‌افزاری با استفاده مجدد هستند و از یک رویکرد توسعه مبتنی بر مؤلفه استفاده می‌شود. در شکل 11 نمایی از دارایی‌های RAGE نمایش داده شده است.

در این معماری دارایی‌ها می‌توانند در سمت کلاینت و سرور قرار گیرند. در سمت کلاینت بازیکن به زمان اجرای بازی دسترسی دارد. در سمت سرور دارایی‌های سمت سرور پشتیبانی می‌شوند. دارایی‌های سمت سرور ممکن است با سرور بازی ادغام شوند یا در سرورهای راه دور قرار گیرند. دارایی‌های سمت کلاینت زمانی اولویت دارند که تعاملات مستقیم و متعدد با موتور بازی روی کامپیوتر محلی مورد نیاز است یا زمانی که باید نتایج فورا در دسترس قرار گیرد. هر پردازشی می‌تواند در سمت کلاینت انجام شود ولی پردازش گسترده دارایی در سمت سرور به منظور جلوگیری از عملکرد ضعیف بازی صورت می‌گیرد. دارایی‌های که داده‌ها را جمع‌آوری و پردازش می‌کنند و به همگام‌سازی بلادرنگ در بین بازیکنان از راه دور نیاز دارند، باید در سمت سرور قرار گیرند. ارتباط بین موتور بازی و انواع سرورها به براساس پروتکل http مانند REST و SOAP صورت می‌گیرد. در سمت کلاینت همه دارایی‌ها به طور کامل با موتور بازی ادغام شدند. در شکل 12 نمایی از معماری توزیع شده کلاینت – سرور برای دارایی‌ها نمایش داده شده است.

۲.۹. قابلیت حمل G-factor در توسعه بازی با استفاده از موتورهای بازی (GSA) [9]

این رویکرد توسعه از جنبه‌های مختلف قابلیت حمل پشتیبانی می‌کند، می‌‌توان بازی‌ها را از یک پلتفرم به پلتفرم دیگر منتقل کرد و دارایی‌ها می‌توانند به موتورهای مختلف منتقل شوند. عناصر قابل حمل بازی شامل منطق بازی، مدل شی و وضعیت بازی است که بیانگر مغز و فاکتور بازی (G-Factor) هستند. هدف این رویکرد قابل حمل کردن مغز موتور بازی است. در این معماری از رویکرد GSA استفاد می‌شود که هدف آن کاهش وابستگی است که G-factor را قادر می‌سازد مستقل از موتور بازی باشد. در GSA از نوعی الگوی MVC برای جداسازی G-factor از موتور استفاده می‌شود که از روش داده‌محور برای اصلاح G-factor استفاده می‌کند.

مکانیزم جداسازی و ارتباط به G-factor اجازه می‌دهد که مستقل از موتور بازی باشد و سبب می‌شود که هنگام مهاجرت به یک موتور جدید عناصر در فضای بازی یعنی وضعیت بازی، مدل شی و منطق بازی سالم و بدون تغییر باقی بمانند. در مقابل هنگام مهاجرت یک بازی توسعه داده شده با استفاده از یک رویکرد توسعه بازی معمولی، هر سه مورد ذکر شده باید دوباره ایجاد شوند یعنی ایجاد دوباره اشیا بازی، مدل شی و نوشتن مجدد منطق بازی به زبان موتور جدید صورت می‌گیرد. مشکلات این روش شامل وابستگی بازی‌ها به زیرساخت نرم‌افزار و موتورهای بازی، استفاده از زبان‌های برنامه‌نویسی و مدل‌های شی خاص موتورها است. قابل حمل کردن G-factor با الگوی MVC به این صورت هست که اشیای بازی در فضای بازی بدون تغییر باقی می‌مانند اما آن‌هایی که در موتور بازی هستند باید دوباره ایجاد شوند، مدل شی در فضای بازی بدون تغییر باقی می‌ماند اما آن‌هایی که در موتور بازی هستند باید دوباره ایجاد شوند و فضای بازی به موتور جدید متصل می‌شود. در شکل 13 نمایی از رویکردهای معمولی توسعه معمولی و رویکرد GSA برای قابلیت حمل بازی نمایش داده شده است.

۲.۱۰ کاربرد طراحی داده‌گرا در توسعه بازی [10]

این رویکرد به بررسی تجربه یک تیم توسعه بازی کوچک در دو پروژه یکی با استفاده از طراحی شی‌گرا و دیگری با استفاده از طراحی داده‌گرا و بررسی عملکرد و قابلیت نگهداری در هر دو پروژه می‌پردازد که نتایج حاصل از این بررسی به این صورت هست که طراحی شی‌گرا برای افرادی علم کامپیوتر را نمی‌دانند آسان‌تر است در حالی که طراحی داده‌گرا به دانش پایه در حوزه کامپیوتر به ویژه سیستم عامل و نحوه کار با حافظه نیاز دارد. طراحی داده‌گرا دارای عملکرد بهتری است. زمان زیادی برای درک ساختار و جریان کد در طراحی داده‌گرا برای مهندسان تازه‌کاری که در مراحل بعدی وارد پروژه می‌شوند، نیاز است. طراحی داده‌گرا به دلیل تعداد الگوهای کمتر، ساختار کلی و اصول ساده، آسان‌تر از طراحی شی‌گرا است. طراحی داده‌گرا استفاده مجدد از طریق ساختار ساده و خودکار ماژول‌های پروژه را تسهیل می‌کند. ساختار خودکار و سادگی ماژول‌های کد در طراحی داده‌گرا، آن را برای توزیع وظایف بین توسعه‌دهندگان را در زمان نوشتن ماژول‌ها آسان می‌کند. بنابراین پروژه‌های طراحی داده‌گرا آسان‌تر توسعه و نگهداری می‌شوند. پروژه‌های مبتتنی بر طراحی داده‌گرا، سریع‌تر نوشته شده می‌شوند و نسبت به طراحی شی‌گرا بخش قابل توجهی از کد مجددا مورد استفاده قرار می‌گیرد. در شکل 14 مهارت‌های مورد نیاز برای طراحی شی‌گرا و در شکل 15 مهارت‌های مورد نیاز برای طراحی داده‌گرا نمایش داده شده است.

۲.۱۱. استفاده از الگوهای طراحی در برنامه‌نویسی بازی [11]

یک طراحی شی‌گرا و یک خانواده از الگوهای طراحی برای توسعه بازی عمومی ارائه شده است. کاربردهای الگوهای ساختاری، الگوی تکوینی و الگوی رفتاری برای ایجاد sprite بازی، جداسازی رفتار از sprite توسط الگوهای استراتژی و فرمان، جداسازی sprite و حالت‌‌ها توسط الگوهای حالت، مدیریت وضعیت بازی و sprite بازی با الگوی طراحی حالت، ارتباط میان sprite با الگوی ناظر و واسطه، تشخیص برخورد با الگوی بازدیدکننده، برخورد و پاداش مختلف در میان spriteها یا بین spriteها و نقشه ارائه شده است. همچنین نحوه اعمال الگوهای طراحی برای مدیریت ارتباطات بین spriteها و NPC توسط الگوی ناظر و الگوی واسطه توصیف می‌شود. اگر الگوهای به درستی و در موارد مناسب استفاده شوند قابلیت نگهداری، توسعه‌پذیری، انعطاف‌پذیری و قابلیت درک می‌تواند مفید باشد و بهبود یابد.

دو دسته الگوی طراحی در توسعه بازی وجود دارد. یک دسته برای توصیف مکانیک‌های بازی در طول توسعه بازی استفاده می‌شود که روی طرح‌های تعاملی تکراری مرتبط با داستان و مکانیک‌های اصلی بازی تمرکز می‌شود و این الگوها مربوط به مهندسی نرم‌افزار نیستند. مانند الگوی مثلثی که زمانی در بازی مورد استفاده قرار می‌گیرد که سه حالت گسسته در بازی وجود دارد و در شکل 16 نمایش داده شده است. دسته دوم الگوهای طراحی در بازی، الگوهای طراحی شی‌گرا در برنامه‌نویسی بازی است که در ادامه معرفی می‌گردند.

با استفاده از الگوی حالت مانند شکل 17، زمانی که در طول توسعه بازی به حالت‌های بیشتری نیاز باشد، به‌ آسانی‌ می‌توان زیرکلاس‌ها را اضافه کرد. زمانی که حالت نیاز به تغییر داشته باشد، می‌توان فقط کلاس مربوط را تغییر داد. الگوی فرمان رفتار بازیکن را به عنوان یک شی به منظور تسهیل توسعه رفتار بازیکن، کپسوله‌بندی می‌کند. با به‌کارگیری الگوهای Factory و استراتژی کد برنامه به آسانی نگهداری می‌شود و تطبیق و سازگاری با تغییرات در توسعه بازی مانند تغییر رفتار، انعطاف‌پذیرتر است که در شکل 18 الگوی فرمان و Factory در بازی نمایش داده شده است. الگوی بازدیدکننده سبب می‌شود برنامه‌نویس عملیات جدیدی را بدون تغییر در کلاس‌های عناصر تعریف کند و زمانی مناسب است که بتوان کارهای مختلفی را برای اشیایی که ساختار کلاسی پایداری دارند، انجام داد و زمانی مهم است که ساختار کلاس بزرگ است. برای برقراری ارتباط بین الگوهای مورد نظر از الگوی ناظر یا واسط استفاده می‌شود. این الگو زمانی که برنامه دارای دو جنبه مجزا است که می‌توانند مستقل از یکدیگر تغییر کنند یا برنامه شامل اشیایی است که هنگام تغییر نیاز به تغییر اشیای دیگر دارند، مورد استفاده قرار می‌گیرد. اگر الگوی واسطه در میان اشیای بازی استفاده شود، به عنوان واسطه بروزرسانی اشیای بازی است. این الگو ارتباط بین همه اشیا را کنترل می‌کند تا چسبندگی بین اجزای بازی را کاهش دهد. در شکل 19 الگوی ناظر، بازدیدکننده و واسط در بازی نمایش داده شده است.

۲.۱۲. قابلیت حمل بازی دیجیتالی STB براساس الگوی MVC [12]

یک معماری مبتنی بر الگوی Model-View-Controller ارائه شده است که سبب می‌شود یک بازی به محیط‌های (Set-Top-Box) STB مختلف بدون تغییر یا با تغییر کمی منتقل شود. الگوی MVC قابل حمل است که می‌تواند روی STB از محیط‌های سخت‌افزاری و نرم‌افزاری مختلف عبور کند. اهداف این معماری شامل بهبود قابلیت حمل و تغییر بازی STB، صرفه‌جویی در زمان توسعه بازی STB، ارائه یک مسیر جایگزین برای توسعه بازی STB، کاهش وابستگی بازی STB به محیط STB خاص و تحقق استانداردسازی منطق بازی و استانداردسازی انتقال بین منطق بازی‌های مختلف مبتنی بر محیط STB متفاوت است.

الگوی MVC در طراحی معماری بازی STB‌ می‌تواند در پلتفرم‌های STB مختلف حمل شود. زمانی که چندین نما برای مدل یکسانی وجود داشته باشد، معماری MVC پیشنهاد می‌شود. هر تغییری که توسط یکی از نماها حمل می‌شود، برای سایر نماها قابل مشاهده است. براساس الگوی MVC، معماری بازی STB در این رویکرد به سه زیرسیستم یعنی فضای بازی، آداپتورها و محیط STB تقسیم می‌شود. فضای بازی شامل حالت ، مدل و رفتار بازی است. فضای برنامه مؤلفه‌هایی مانند رابط برنامه‌نویسی برنامه (API)، مفسر برنامه‌نویسی، سوکت‌ها و ذخیره‌سازی ماندگار است که برای مدیریت بازی و ارتباط در محیط STB مورد استفاده قرار می‌گیرند. معماری پیشنهادی دقیقا از الگوی MVC پیروی نمی‌کند، زیرا پیوند مستقیم بین نما و مدل را می‌شکند و فقط اجازه ارتباط از طریق کنترل‌کننده را می‌دهد که علت آن، حذف یکی از مسئولیت‌ها با استفاده از MVC است که منجر به اتصال نزدیک بین نما و مدل می‌شود. عناصر مربوط به اشیای حالت بازی باید به محیط اضافه شوند که از طریق ویرایشگر سطح انجام می‌شود. در شکل 20 نمایی از این معماری نمایش داده شده است.

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

۲.۱۳. معماری Hydra: یک معماری نظیر به نظیر چند نفره بزرگ برای توسعه‌دهندگان بازی [13]

سیستم Hydra که یک معماری نظیر به نظیر برای بازی‌های آنلاین بزرگ چند نفره است ارائه شده است. با پشتیبانی از یک مدل برنامه‌نویسی کلاینت - سرور افزوده جدید با پروتکلی، بدون استفاده از قفل یا کننترل همروندی، سازگاری در پیام‌های دریافتی را در زمان خرابی گره‌ها تضمین می‌کند و پیچیدگی‌های مربوط به بازیابی خرابی گره را پوشش می‌دهد. توسعه‌دهندگان بازی می‌‌توانند از مزایای این معماری بدون مدیریت پیچیدگی‌های مربوط به ریزش شبکه، استفاده کنند. ویژگی کلیدی آن توسعه رابط برنامه‌نویسی برای استفاده آسان و بصری است که می‌تواند در لایه شبکه پشتیبانی شود. این معماری سربار پیام کمی را تحمیل می‌کند و باعث کاهش زمان پاسخ و تاخیرها می‌گردد، بنابراین مقیاس‌پذیر است. همچنین مجموعه‌ای از پروتکل‌ها را برای پشتیبانی از روابط کاربری مورد نیاز پشتیبانی می‌کند.

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

معماری Hydra یک سیستم توزیع‌شده نظیر به نظیر است و هر گره Hydra شامل یک ماژول کلاینت و یک سرور Hydra است. ماژول کلاینت در این سیستم شامل دو مؤلفه کلاینت بازی و پروکسی کلاینت است. به جای ارسال مستقیم پیام به شبکه، پیام را از طریق پروکسی ارسال می‌کند، به طور مشابه به جای خواندن مستقیم از شبکه، پیام‌های دریافتی برای کلاینت بازی توسط پروکسی کلاینت در صف اولویت قرار می‌گیرند. سرورهای بازی به عنوان مؤلفه‌هایی هستند که برش نام دارند و حالت بازی را برای منطقه خاصی از دنیای مجازی مدیریت می‌کنند و سرور Hydra ممکن است شامل چندین برش باشد. ممکن است زمانی که تعداد کلاینت‌ها کم است، یک host چندین ناحیه از دنیای مجازی را به طور همزمان مدیریت کند. همچنین یک گره ملاقات وجود دارد که هر زمانی که یک گره جدید به سیستم می‌پیوندد، پرس و جو می‌شود و این مؤلفه ردیاب سراسری نامیده می‌شود. علاوه بر این به عنوان یک نفطه تماس برای نودهای جدید عمل می‌کند. همچنین سرورها و برش‌ها را در سیستم ردیابی می‌کند. در شکل 21 نمایی از معماری سیستم Hydra نمایش داده شده است.

۲.۱۴. یک چارچوب معماری سرویس‌گرا برای بازی‌های جدی آموزشی [14]

در این مقاله از مدل مبتنی بر نظریه فعالیت برای بازی‌های جدی (ATMSG) برای شناسایی اجزای مرتبط استفاده شده است که می‌تواند برای بازی‌های مختلف دوباره مورد استفاده قرار گیرد. هدف اصلی این رویکرد شناسایی مؤلفه‌های کاندید بازی‌های جدی است که می‌تواند به عنوان سرویسی برای بازی‌ها با سبک‌ها و دامنه‌های مختلف توسعه یابد. در مدل جدید توسعه‌یافته، مؤلفه‌های مختلف را در سطوح مختلف یک بازی به هم متصل می‌شوند. در این مدل از نظریه فعالیت برای ترسیم مدلی که شامل چند مؤلفه سطح پایین مختلف در یک بازی جدی آموزشی است، استفاده می‌شود و نحوه اتصال مؤلفه‌ها، اهداف سطح بالای آموزشی و سرگرمی یک بازی را نمایش می‌دهد. در ATMSG بازی‌های جدی آموزشی در 4 فعالیت مورد استفاده قرار می‌گیرند که شامل بازی، یادگیری، آموزش داخلی که در داخل بازی و آموزش بیرونی توسط مربی در بیرون از بازی است. بر اساس شکل 22 در این مدل فعالیت‌ها به دنباله‌ای از اقدامات با ابزارهایی با اهداف خاص، تجزیه می‌شوند که مجموعه‌ای از دسته‌ها را ارائه می‌دهد که طبقه‌بندی مؤلفه‌های بازی‌های جدی را نشان می‌دهند.

برخی عملیات در بازی می‌توانند به عنوان سرویس، پیاده‌سازی شوند که شامل سرویس تعامل بین بازیکنان برای جمع‌آوری، نمایش و مقایسه امتیازها، سرویس تعامل یادگیرنده و مربی برای پرس و جوی بازیکنان یا تعامل در فرایند یادگیری، سرویس ذخیره و بازیابی اطلاعات برای موضوعات مرتبط به دانش داخل بازی، دامنه یادگیری، اتصال به پایگاه‌های دانش و تبدیل اطلاعات به فرمت‌های مورد استفاده در بازی، سرویس بازخورد برای ارسال نتایج ارزیابی درون بازی به بازی، سرویس ارزیابی شامل ماژول‌هایی برای ارزیابی کمی به صورت خودکار، ارزیابی کیفی توسط مربی، ارزیابی مشارکت، تحلیل یادگیری و استفاده از داده‌ها برای شناسایی الگو،‌ سرویس تطبیق‌پذیری برای تجمیع اطلاعات حاصل از چند سرویس ارزیابی مختلف، ارزیابی این اطلاعات، تصمیم‌گیری در مورد نحوه واکنش بازی و ارائه اطلاعات به بازی، سرویس اتصالات بازی برای ایجاد ماژول‌های آداپتور و مدل‌های داده به منظور مرتبط کردن سرویس‌های خارجی را به بازی، سرویس پروفایل کاربری برای فعال کردن تعامل، همگام‌سازی و ویژگی‌های پایدار در بازی‌های مختلف و تنظیمات یادگیری است. در شکل 23 نمایی از سرویس‌ها در چارچوب SOA در بازی‌های جدی نمایش داده شده است.

• سایر حوزه‌های معماری نرم‌افزار

در این بخش به مرور و بررسی کارهای پیشین با استفاده از سایر حوزه‌های معماری نرم‌افزار در توسعه نرم‌افزار بازی پرداخته می‌شود.

۲.۱۵. یک معماری نرم‌افزار برای بازی‌ها [15]

یک معماری عمومی برای نرم‌افزار بازی بلادرنگ توصیف شده است. از این معماری برای به حداکثر رساندن قابلیت استفاده مجدد از ماژول‌های سیستم در بازی‌های تک نفره و چند نفره استفاده می‌شود. این معماری با قرار دادن سیستم شی برای کمینه کردن چسبندگی، اجزای عمومی بازی مانند موتور را از اجزای خاص بازی مانند شبیه‌سازی به آسانی جدا می‌کند و تاثیر ترکیب حالت‌های بازی چندنفره را کمینه می‌کند. این معماری به راحتی با پیکربندی سرور کلاینت برای بازی‌های چند نفره منطبق می‌شود و این جداسازی منجر به مهاجرت از معماری بازی تک نفره به معماری بازی چند نفره شبکه‌ای می‌شود.

این معماری دارای ساختاری سطح بالا است و طبق شکل 24 دارای مؤلفه‌های موتور بازی، شبیه‌سازی و مدیر داده با سیستم شی تعامل دارند. موتور بازی مسئول نمایش بازی برای بازیکن و دریافت ورودی‌های بازیکن است و شامل تولید گرافیک، صدا و بازخورد به بازیکن است. سیستم شبیه‌سازی مهم‌ترین بخش بازی و مسئول بروزرسانی حالت دنیای بازی در پاسخ به ورودی‌های بازیکن است و قوانین بازی را حفظ می‌کند. مدیر داده مسئول بازیابی داده بازی از سیستم فایل یا سایر مخازن ماندگار و مدیریت ذخیره‌سازی و بازیابی حالت بازی برای ذخیره و بارگذاری عملکرد بازی است. سیستم شی مسئول نگهداری اطلاعات وضعیتی است که همه اشیا را در دنیای بازی توصیف می‌کند. این سیستم در حافظه برای دسترسی بلادرنگ به تمام اطلاعات وضعیت بازی قرار دارد. مزیت اول این رویکرد کاهش نیاز به تعریف خاص داده‌های در حال جریان بین ماژول‌ها است. یک مسیر داده بین موتور بازی و شبیه‌سازی وجود دارد که از طریق سیستم شی نیست. این مسیر برای انتقال اطلاعات ورودی بازیکن از موتور بازی به شبیه‌سازی است، تعامل بین موتور بازی سیستم شی را برای یک رابط فقط خواندنی محدود می‌کند و موجب تسهیل پردازش می‌شود که توسط لایه شبکه در بازی چندنفره انجام می‌شود.

موتور بازی مسئول تعامل با بازیکن از طریق سخت‌افزار و سیستم عامل است. یکی از ویژگی‌های ماژول‌های موتور بازی چسبندگی کم یا عدم چسبندگی است و جریان داده از طریق آن‌ها یک‌طرفه است. ماژول کنترل شبیه‌سازی مطابق شکل 25، اطلاعات ورودی بازیکن را از موتور بازی دریافت می‌کند و به ماژول هوش مصنوعی بازیکن منتقل می‌کند. ماژول فیزیک، مربوط به تعامل اشیا در دنیای مجازی براساس خواص فیزیکی جهان است. ماژول هوش مصنوعی به داخل و فرایند تصمیم‌گیری در اشیا متحرک می‌پردازد. ماژول منطق بازی به مسائلی که بخشی از دنیای مجازی نیستند و بازی آن‌ها را انجام می‌دهد می‌پردازد و محاسبات و محدودیت‌هایی هستند که از قوانین بازی استنتاج می‌شوند. این ماژول‌ها به طور مستقیم با یکدیگر تعامل ندارند. آن‌ها از طریق اطلاعاتی که حالت را اشیا در بازی توصیف می‌کنند و در سیستم شی ذخیره می‌شوند، با یکدیگر ارتباط دارند. در بازی شبکه‌ای چندنفره مطابق شکل 26، تعدادی از بازیکنان در یک محیط مجازی تعامل دارند که مؤلفه شبیه‌سازی روی سرور پردازش می‌شود و اجرا و رابط موتور بازی روی کامپیوترهای فردی بازیکنان و کلاینت پردازش می‌شود. چون تمام ارتباطات بین شبیه‌سازی و موتور بازی از طریق سیستم شی صورت می‌گیرد، هر کلاینت باید یک کپی از سیستم شی داشته باشد که توسط شبیه‌سازی بروزرسانی می‌شود.

۲.۱۶. استراتژی قابلیت همکاری برای توسعه بازی‌های جدی [16]

به محیط تکنولوژی زیرساخت توسعه بازی‌‌های جدی و قابلیت همکاری می‌پردازد. بازی‌های جدی قابلیت همکاری را فراهم می‌سازد و سبب افزایش عمق و توسعه موارد آموزشی در دسترس برای یادگیرندگان می‌شود در حالی که زمان و هزینه کلی توسعه را کاهش می‌دهد. این رویکرد، سه عنصر کلیدی شامل مؤلفه‌های اصلی در بازی جدی (مکانیک بازی، انجام بازی، موتور گرافیکی و اشیا گرافیکی)، اکوسیستمی که بازی جدی در آن پیاده‌سازی می‌شود (توسعه پلتفرم‌ها، زبان‌های برنامه‌نویسی و ارتباطات LMS) و فاکتورهای خارجی فراتر از جنبه‌های تکنیکی اصلی بازی جدی (ارزیابی، کاربرد، طبقه‌بندی و واژه‌ نامه‌های اصطلاحات) را ادغام می‌کند که بر قابلیت همکاری بازی‌های جدی اثر می‌گذارند. هدف قابلیت همکاری، پشتیبانی از تبادل مؤثر اطلاعات براساس داده ثابت و خاص و روش‌های استاندارد است. هدف سناریوهای قابلیت همکاری افزایش تعامل بین توسعه‌دهندگان بازی با استفاده از راه‌حل‌های جایگزین استاندارد است. چارچوب قابلیت همکاری چندبعدی بازی‌های جدی، به منظور تسهیل تحلیل عمیق موضوع و همچنین درنظر گرفتن اکوسیستم توسعه بازی‌های جدی ایجاد شده است که در شکل 27 نمایش داده شده است.

• حوزه خط تولید نرم‌افزار

در این بخش به مرور و بررسی کارهای پیشین در حوزه خط تولید نرم‌افزار در توسعه نرم‌افزار بازی پرداخته می‌شود.

بهبود توسعه بازی دیجیتالی با خطوط تولید نرم‌افزار [17]

یک فرایند سیستماتیک برای بهره‌برداری از خط تولید نرم‌افزار برای توسعه بازی برای هر دو زبان دامنه خاص و تولیدکنندگان برای زیردامنه‌های بازی است که از تجزیه و تحلیل دامنه بازی برای ایجاد دارایی‌های اصلی و معماری‌های مرجع برای یک خط تولید نرم‌افزار بازی استفاده می‌کند و ویژگی‌های بازی را در نظر می‌گیرد. همچنین سبب کاهش پیچیدگی برای مصرف موتورهای بازی، تقسیم خودکار وظایف توسعه بازی به بخش‌های کوچکتر، تحویل افزایشی مقدار برای اولویت‌بندی زیردامنه‌های بازی، دارایی‌های خاص دامنه متناسب با ویژگی‌های منحصر به فرد بازی و افزایش اعتماد به نتیجه بازی‌ها می‌شود. در رویکرد پیشنهادی ویژگی های بازی در نظر گرفته می‌شودو این رویکرد به صورت خطی انجام می‌شود ولی باید انجام فعالیت‌ها در تکرارها، تحلیل نمونه‌ها، استخراج ویژگی‌ها، بررسی کد، مدلسازی و پیاده‌سازی دارایی‌ها به صورت افزایشی انجام شوند. با استفاده از یک رویکرد توسعه خاص دامنه سیستماتیک که برای بازی‌های دیجیتالی جریان دارد، توسعه‌دهندگان و طراحان می‌توانند دامنه‌های بازی هدف و تجزیه و تحلیل دارایی‌های اصلی در یک SPL بازی را متصل کنند. در شکل 28 خط تولید نرم‌افزار برای بازی‌ها نمایش داده شده است.

۳. ارزیابی

در این بخش ابتدا کارهای پیشین تحلیل و ارزیابی می‌شوند و سپس مقایسه و بررسی آن‌ها براساس ویژگی‌هایی در جدول 1 ارائه می‌گردد.

استفاده از رویکردهای مدل محور به منظور توسعه رابط کاربری بازی، افزایش یادگیری، ایجاد انگیزه در کاربران، توسعه منعطف، سریع و آسان بازی، ایجاد انعطاف‌پذیری، افزایش بهره‌وری، دسترس‌پذیری، قابلیت همکاری، افزایش سطح انتزاع، کاهش زمان، توسعه بازی مستقل از پلتفرم، شناسایی مؤلفه‌های اصلی، رفع ضعف ابزارهای سازنده، خودکارسازی نمونه اولیه در توسعه بازی، امکان استفاده مجدد و تسهیل مدلسازی، توسعه نیمه خودکار بازی براساس سبک بازی، مدیریت فرامدل، شاخص‌گذاری سناریوها و انطباق مدل تولید شده با فرامدل اصلی صورت می‌گیرد.

استفاده از الگوهای طراحی و معماری به منظور بهبود بهره‌وری و کیفیت بازی، عدم نیاز به تولید مجدد مؤلفه‌ها، ساختارهای مشترک و مستقل از پلتفرم، ادغام و استفاده مجدد مؤلفه‌ها، قابلیت حمل دارایی‌ها در پلتفرم‌های مختلف، تقویت انسجام داخلی و پتانسیل بازی، قابلیت نگهداری، مقیاس‌پذیری، توسعه سریع، آسان و کم هزینه، افزایش عملکرد، جداسازی عناصر اصلی بازی از موتور بازی، حل مشکل چسبندگی بین بازی و محیط بازی، استفاده از طراحی داده‌گرا با ساختار و اصول ساده‌تر و الگوهای کمتر نسبت به طراحی شی‌گرا، قابلیت استفاده مجدد بخش قابل توجهی از کد، مدیریت عناصر بازی و پیچیدگی، تضمین سازگاری در زمان خرابی و رفع پیچیدگی‌های آن، کاهش زمان پاسخ و سربار، افزایش قابلیت همکاری و سازگاری بین مؤلفه‌های بازی، شناسایی مؤلفه‌های مرتبط در بازی و کاهش زمان و هزینه ورود به بازار صورت می‌پذیرد.

استفاده از سایر معماری‌ها به منظور کمینه کردن چسبندگی، جداسازی مؤلفه‌های عمومی و خاص بازی، قابلیت استفاده مجدد از ماژول‌ها، ارتباط ماژول‌ها با یکدیگر و تسهیل بررسی و درک آن‌ها، توسعه زیرساخت برای قابلیت همکاری بازی و ادغام عناصر کلیدی در بازی انجام می‌شود. استفاده از خط تولید نرم‌افزار به منظور ساده‌سازی زیردامنه‌های بازی، ایجاد دارایی‌های اصلی و خاص دامنه، افزایش قابلیت اعتماد در نتایج بازی، کاهش پیچیدگی موتور بازی و ریزدانگی وظایف صورت می‌گیرد.

۴. پیشنهادات

در این بخش پیشنهادات و کارهایی در حوزه معماری نرم‌افزار که می‌توان در آینده به منظور بهبود طراحی و توسعه نرم‌افزار بازی انجام داد، ارائه می‌گردد.

استفاده از رویکرد‌های مدل محور برای توسعه سایر بخش‌های بازی، خودکارسازی سایر لایه‌ها و بخش‌های بازی، استفاده از رویکردهای معماری نرم‌افزار در سایر سبک ها و انواع بازی‌های تک‌نفره و چندنفر، استفاده از رویکردهای معماری نرم‌افزار به منظور دستیابی به سایر ویژگی‌های کیفی، قابل حمل کردن سایر بخش‌های بازی مانند مکانیک‌ها، داینامیک‌ها و مؤلفه‌های بازی، استفاده از سایر الگوهای طراحی برای برنامه‌نویسی بازی، استفاده از الگوهای طراحی برای مدیریت و ایجاد سایر عناصر بازی، استفاده از سایر الگوهای معماری در توسعه بازی، به کاربردن ترکیبی از چند الگوی طراحی در برنامه‌نویسی بازی، به کار بردن ترکیبی از چند الگوی معماری در توسعه بازی، در نظر گرفتن مؤلفه‌های دیگر بازی به عنوان سرویس در معماری سرویس‌گرا، استفاده از معماری میکروسرویس در توسعه بازی، قابل حمل کردن سایر عناصر و مؤلفه‌های بازی، استفاده از سایر رویکردهای موجود در خط تولید نرم‌افزار در فرایند طراحی و توسعه بازی و استفاده از رویکردهای معماری نرم‌افزار بازیگونه‌سازی برای دستیابی به ویژگی‌های کیفی و افزایش آن‌ها و بهبود طراحی، توسعه و یکپارچه‌سازی آن و کاهش زمان، هزینه و پیچیدگی از جمله کارهایی است که می‌توان در آینده به منظور بهبود طراحی، توسعه و کیفیت انواع بازی‌ها انجام داد.

۵. جمع‌بندی

با افزایش روزافزون بازی‌ها، گسترش و پیچیدگی نرم‌افزار بازی، پلتفرم‌ها و برنامه‌هایی که آن را هدایت می‌کنند و محدودیت تکنولوژی‌های موجود طراحی، توسعه و یکپارچه‌سازی نرم‌افزار بازی دشوار می‌گردد و ماژول‌های موجود در آن پیچیدگی و چسبندگی بیشتری دارند که افزایش زمان و هزینه تولید و کاهش کیفیت و عملکرد بازی را به همراه دارد. در نتیجه تیم‌های توسعه‌دهنده بازی بزرگتر می‌شوند و وظایف تخصصی‌تری را انجام می‌دهند. بنابراین نرم‌افزار بازی هم مشابه سایر نرم‌افزارها برای بهبود عملکرد، کیفیت، دستیابی به ویژگی‌های کیفی مؤثر و یکپارچه‌سازی نیاز به روش‌های موجود در معماری نرم‌افزار دارد تا زمان و هزینه تولید بازی و ورود به بازار کاهش یابد و سبب رضایت بازیکنان از بازی گردد.

در این مقاله در ابتدا تعدادی از کارهای انجام شده در حوزه استفاده از معماری نرم‌افزار در توسعه نرم‌افزار بازی با استفاده از رویکردهای مدل محور، الگوهای طراحی و معماری، سایر رویکردهای موجود در حوزه معماری نرم‌افزار و خط تولید نرم‌افزار به منظور بهبود توسعه، طراحی و یکپارچه‌سازی انواع بازی‌ها، دستیابی به ویژگی‌های کیفی، کاهش زمان، هزینه و پیچیدگی و ... در برنامه‌های بازی پرداخته شد. سپس تحلیل و ارزیابی رویکردهای پیشین و مقایسه و بررسی آن‌ها براساس ویژگی‌های مورد نظر بیان گردید. در پایان نیز پیشنهاداتی برای بهبود عملکرد، کیفیت، طراحی و توسعه نرم‌افزار بازی در حوزه معماری نرم‌افزار به منظور تحقیق و توسعه در آینده ارائه گردید.

۶. منابع و مراجع

[1] Minovic, Miroslav, et al. "Model driven development of user interfaces for educational games." 2009 2nd Conference on Human System Interactions. IEEE, 2009.

[2] do Prado, Ely Fernando, and Daniel Lucrédio. "A flexible model-driven game development approach." 2015 IX Brazilian Symposium on Components, Architectures and Reuse Software. IEEE, 2015.

[3] Tang, Stephen, Martin Hanneghan, and Christopher Carter. "A platform independent game technology model for model driven serious games development." Electronic Journal of e-Learning 11.1 (2013): pp61-79.

[4] Reyno, Emanuel Montero, and José Á. Carsí Cubel. "Automatic prototyping in model-driven game development." Computers in Entertainment (CIE) 7.2 (2009): 1-9.

[5] Vargas, Rosa, et al. "MDA Game Design for Video Game Development by Genre." Demos/Posters/StudentResearch@ MoDELS. 2013.

[6] Aouadi, Nada, et al. "MDA approach for reusability in serious game and e-learning design." International Conference on Web-Based Learning. Springer, Cham, 2016.

[7] Hu, Wenfeng. "A common software architecture for educational games." International Conference on Technologies for E-Learning and Digital Entertainment. Springer, Berlin, Heidelberg, 2010.

[8] Van der Vegt, Wim, et al. "RAGE architecture for reusable serious gaming technology components." International Journal of Computer Games Technology 2016 (2016).

[9] BinSubaih, Ahmed, and Steve Maddock. "G-factor portability in game development using game engines." Proceedings of the 3rd International Conference on Games Research and Development. 2007.

[10] Fedoseev, K., et al. "Application of Data-Oriented Design in Game Development." Journal of Physics: Conference Series. Vol. 1694. No. 1. IOP Publishing, 2020.

[11] Qu, Junfeng, Yinglei Song, and Yong Wei. "Applying design patterns in game programming." Proceedings of the International Conference on Software Engineering Research and Practice (SERP). The Steering Committee of The World Congress in Computer Science, Computer Engineering and Applied Computing (WorldComp), 2013.

[12] Huang, Jun, and Guangping Chen. "Digtal stb game portability based on mvc pattern." 2010 Second World Congress on Software Engineering. Vol. 2. IEEE, 2010.

[13] Chan, Luther, et al. "Hydra: a massively-multiplayer peer-to-peer architecture for the game developer." Proceedings of the 6th ACM SIGCOMM workshop on Network and system support for games. 2007.

[14] Carvalho, Maira B., et al. "Towards a service-oriented architecture framework for educational serious games." 2015 IEEE 15th International Conference on Advanced Learning Technologies. IEEE, 2015.

[15] Doherty, Michael. "A software architecture for games." University of the Pacific Department of Computer Science Research and Project Journal (RAPJ) 1.1 (2003).

[16] Stãnescu, Ioana Andreea, et al. "Interoperability strategies for serious games development." Internet Learning 2.1 (2013): 6.

[17] Furtado, Andre WB, et al. "Improving digital game development with software product lines." IEEE software 28.5 (2011): 30-37.

«این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است»