post

طراحی موتور بازی مؤلفه گرا

کارشناس : مهندس امیرحسین فصیحی
نخستین همایش ملی بازی های رایانه ای دانشگاه صنعتی شریف

گرداوری و تدوین گزارش : مریم ثابت قدم اصفهان
ناظر علمی : امیرحسین فصیحی

حقوق این گزارش برای سایت انیمیشن دیتا محفوظ است

موضوع مورد بحث من؛ یکی از زیر مجموعه های Gameplay Foundation System به نام GameObject Model است که در مورد آن توضیح بیشتری خواهم داد. در طراحی این GameObject Model ، یکی از روشهای مورد استفاده Component based Object Model یا آبجکت مدل مؤلفه گرا است.

اگر بخواهیم آناتومی موتور بازی را معرفی کنیم ؛ باید بگویم که این آناتومی از اجزای مختلفی نظیر Low level systems تشکیل می شود. وجود این اجزا باعث ارتباط برنامه و موتور بازی با سیستم عامل ؛ مانند مدیریت فایل ، مدیریت حافظه و غیره می گردد .

Input systems ، مؤلفه هایی هستند که باعث می شود بازی شما با کنترل mouse و keyboard, joystick کار کند.
Rendering system در اکثر موتورهای بازی بخش مهمی است . در واقع بخش گرافیکی است که بسیاری از بازی های مطرح دنیا در این ارتباط بسیار تبلیغ کرده و آنرا بعنوان نقطه قوت خود ارزیابی می کنند.

ممکن است بعضی از موتورهای بازی از Physic جدی استفاده کنند. برخی دیگر نیز ممکن است Physic ساده ای را بکار گیرند و برخی دیگر شاید از Physic موجود بهره گرفته و یا خودشان آن را شبیه سازی کنند.
Collision به معنی “برخورد” از اولین بازی رایانه ای یعنی Pong ( با دو چوب و یک توپ در وسط ) از نقش در خور توجهی برخوردار بوده است . آنچه در هر بازی اهمیت دارد ؛ آن است که بدانید اشیاء چه زمانی با یکدیگر برخورد می کنند و طی آن چه اتفاقی رخ می دهد؟
Animation system بخش دیگری است که ممکن است بخواهید آنرا به صورت Vertex animation نشان داده و یا یک سری نقطه را انیمیت کنید. گاهی اوقات نیز به صورت Skeleton animation است و در اینصورت یک اسکلت برای کاراکتر تعریف می شود. در هر صورت، Animation نیز یکی از اجزای مهم موتور بازی بشمار می آید.
AI یا هوش مصنوعی ، دریایی بشمار می آید. حالا اینکه یک موتور بازی چقدر روی هوش مصنوعی اش کار کرده ؛ قابل بررسی و تأمل است. در هر حال ، هوش مصنوعی نیز از اجزای مهم موتور بازی تلقی می گردد.
Networking یا شبکه سازی نیز از دیگر اجزای مهم است. برخی از موتورهای بازی از آپشن شبکه نیز پشتیبانی می کنند.
خب ؛ هر یک از این اجزاء تعریف مشخصی دارند. اگر بخواهیم آنرا از رویکرد سیستمی مد نظر قرار دهیم ؛ ورودی ها و خروجی ها مشخص اند.چیزی که قابل بررسی است ؛ در واقع همان Gameplay foundation system یا سیستم های زیر بنایی Gameplay است.
جعبه زیر را چنان مورد ملاحظه قرار دهید که گویی این جعبه مستطیل ، بازی و موتور بازی باشد:

می دانید که هر بازی از Engine (موتور بازی ) خاص خود استفاده می کند . بازی God of war در عین حال که بازی است ؛ اما از یک موتور بازی هم بهره می گیرد. این مرز کجاست؟ بحث این خط ، آن است که مرز بین بازی و موتور بازی را چه کسی تعریف کرده و کجا قرار دارد؟ و چقدر می تواند بالا و پایین بیاید؟ در واقع چه کسی این حدود را مشخص می کند؟
در تعریف هایی که برای موتور بازی مطرح شده است ؛ موضوع ” قابل استفاده بودن مجدد ” از مبحث های بسیار جدی تلقی می شود. یعنی اینکه موتور بازی برای چندین بازی قابل استفاده باشد. در عین حال ، مانند تعاریفی که در مهندسی نرم افزار برای موتورهای بازی نظیر Search Engine بکار می رود؛ هسته ای است که از قابلیت استفاده مجدد برخوردار بوده و باید برای این سیستم موجود باشد.
حال ، سایت هایی مانند ویکی پدیا ، تعاریفی برای موتور بازی بکار می برند : اینکه موتور بازی ، نرم افزاری است که با آن می توانید بازی بسازید. خب ؛ این هم به هرحال ، تعریفی است. معهذا آنچه ما می خواهیم در مورد آن به صحبت بپردازیم این است که فرض می کنیم آن سیستم هایی که در اسلاید اول وجود دارد ؛ نظیر Physic , Input, Low level خیلی مستقل تر هستند. برای یک موتور بازی فرقی نمی کند در چه نوع بازی استفاده شده ؟ برای Input شما مهم نیست که ژانر بازی شما استراتژیک است یا RPG . ممکن است از direct input و یا از OIS بهره گیرد.

Gameplay foundation system آن قسمت از موتور بازی است که دقیقاً مرز با خود بازی را تشکیل می دهد.
حال پرسشی مطرح است مبنی بر آنکه چه چیز بالای این مستطیل قرار دارد؟
بطور کلی ، در داخل این مستطیل یک سری دیتا و فرایند موجود است. دیتای بالای آن شامل content و مدل های تان نظیر تکسچر ، mesh, ، صدا ، فایل های انیمیشن و غیره است.
آن وسط نیز ؛ منطق گیم وجود دارد ، به نحوی که در مقابل هر عملکرد یا هر object که در نرم افزار تعریف می شود ؛ یک سری اتفاقات بوقوع می پیوندد. اینها ، فرایند متعلق به منطق خاص هر بازی است که در بالای این خط قرار می گیرد.
ولی برای پیاده سازی این فرایند، نظیر اسکریپت نویسی در سمپل و ابزار گرافیکی موجود در نرم افزارهایی نظیر UDK ، تمهیداتی وجود دارد که به ما اجازه این نوع عملکرد ها را داده و ارتباط با سیستم های زیرین نظیر Physic و Input را مهیا می کند ؛ اینها ، نمونه ای از چیزی است که اصطلاحاً Gameplay foundation system تعبیر می شود.
در این میان ، بحث ژانر نیز مطرح می گردد:

چه چیز ژانر یک بازی را مشخص می کند؟ یعنی چه وقتی می گوییم که یک بازی استراتژیک است ؟ Cry Engine3 یکی از انجین های خوب بشمار می آید. اما وقتی کسی بخواهد یک بازی استراتژیک بسازد ؛ در مورد خرید آن کمی با دغدغه هایی روبروست. در آمارهایی که از موتورهای بازی اخذ شده بود ؛ یکی از پرسشها این بود که مهمترین دغدغه شما در خرید انجین چیست؟ تصور می کنم دومین یا سومین پاسخ به آن ، این بوده که آیا می توان نیازهای خود را با این موتور بازی برآورده ساخت؟ خب ، این نگرانی از کجا ریشه می گیرد؟ دقیقاً از شیوه استفاده Gameplay foundation ( که در مورد اجزای آن به تفصیل صحبت خواهم کرد) و نحوه یکپارچه سازی آن با موتور بازی سرچشمه می یابد .
یعنی وقتی قرار است یک بازی خاص به شما داده شود ؛ جایگاه این خط فاصله میان بازی و موتور بازی بسیار مهم است. اگر بالا باشد ؛ کار شما آسان است و در غیر اینصورت ، هر چه پایین تر آید ؛ کار شما به مراتب دشوار تر می شود.
اگر بخواهید ژانر بازی را تغییر دهید و خط بالا باشد ؛ یعنی یک سری سرویس های بازی به شما تعلق می گیرد و اگر بخواهید بازی RPG تولید کنید ؛ مجبورید از یک سری سرویس ها و خدمات صرفنظر کرده و خودتان آن ها را پیاده سازی نمایید. به نظر می رسد عمده تفاوت میان ژانرهای موتور بازی، ریشه در همین قسمت Gameplay foundation دارد.

طراحی موتور بازی مؤلفه گرا-صفحه2

به جز تعدادی از بازی های بسیار پیچیده ، اغلب بازی ها از Nvidia PhysX یا Havok استفاده می کنند.چیزی که برای تعریف ژانر و انتخاب انجین مهم است ؛ بیشتر مبتنی بر سیستم های زیر بنایی است که مرز میان بازی و موتور بازی هستند.خب، این سیستم های زیر بنایی چه نوع سیستم هایی هستند؟

بازی را از یک سری اشیاء بازی GameObject model نظیر ، یک میز ، چراغ ، ببر ، کاراکتر دشمن ، اسلحه و غیره می سازند. اینکه چطور یک GameObject به یک مدل تبدیل می شود ؛ مبحثی بسیار مهم است.
مدیریت Level و Streaming بدین معنا است که دیتا از کجا می آید؟ همانطور که گفتیم ، ژانر بازی به سیستم های زیر بنایی مرتبط است. بعنوان مثال ، یکی از دغدغه های تولید کنندگان بازیMMO در خرید Unreal Engine3 این است که Streaming جهان یک جور دیگر است و باید بطور پیوسته کاراکتر در آن جهان باشد و نمی توان از جای دیگر Load کرد. پس در می یابیم که به این سیستم زیربنایی کاملاً مرتبط است.
در Real – Time object model ، تمام انجین های بازی یک نوع نرم افزار خاص هستند که در مهندسی نرم افزار به آن Real – Time simulation گویند.یعنی آبجکت هایی که در هر فریم بطور real – time آپدیت شوند. چگونگی پیاده سازی این فرایند نیز از مباحثی است که در سیستم های زیر بنایی حائز اهمیت است.
مبحث دیگر که بین خود آبجکت ها و یا رویدادهای بازی مطرح می شود ؛ آن است که پشتیبانی از اسکریپت بسیار مهم است. Scripting ممکن است text based ( مانند Lua , Python ) و یا graphical ( مانند kismet unreal ) باشد.
در حقیقت ؛ در ژانر بازی نوع Scripting بسیار مهم است. بازی RPG بدون Scripting تقریباً ناممکن است. ولی احتمال دارد که یک بازی ساده بدون نیاز به Scripting نیز تولید گردد. پس در انتخاب موتور بازی ، این سیستم زیر بنایی است که نقش عمده ای ایفا می کند. اینکه Scripting چه امکاناتی به شما داده و تا چه حد از قابلیت Customize برخوردار است ؛ مبحث دیگری است.
Objectives and game flow management به مدیریت اتفاقات بازی اطلاق می گردد. برخی بازی ها روند خطی و برخی دیگر هم روند غیر خطی و بسیار پیچیده دارند. بطور مثال بازی God of war از نظر اتفاقات داستانی ، خطی است و یک سری رویدادهای متوالی رخ می دهد . اما بازی Heavy Rain دقیقاً عکس این بوده و غیر خطی و شامل انواع پایان ها می باشد.
پس اگر می خواهید انجینی را مورد استفاده قرار دهید که امکان فرایند غیر خطی از نظر مدیریت game foundation را فراهم آورد و در عین حال در صدد تولید بازی به سبک Heavy Rain هستید ؛ با مشکلات بسیاری مواجه خواهید بود و باید خودتان جاهای خاصی را بسازید. به game flow management ، اصطلاحاً Side یا ستون فقرات بازی نیز می گویند.
یکی از سیستم های زیر بنایی اصلی ، Runtime GameObject model است:

در اینجا دو مقوله Tool- side design و Runtime design مورد بررسی قرار می گیرند.
منظور از Tool – side design آن چیزی است که شما بهنگام استفاده از Editor مشاهده می کنید. در ادیتور نرم افزار UDK می توان آبجکت های فیزیکی را در صحنه قرار داد. ولی آیا شما می بینید که اینها چگونه پیاده سازی شده اند؟ پس منظور آن چیزی است که کاربران و طراحان مشاهده می کنند.
منظور از Runtime design آن چیزی است که پیاده سازی می گردد.
ممکن است در Tool – side design ، گیم آبجکت را یک شئ ببینید ؛ در صورتی که در پیاده سازی اصلاً آبجکت نباشد. یا اینکه شئ که شما در ادیتور مشاهده می کنید ؛ در واقع چندین آبجکت در پیاده سازی باشد . و یا اینکه آبجکت مشاهده شده در ادیتور از نظر برنامه نویس تنها یک شناسه باشد.

خب ، Runtime GameObject model باید از چه امکاناتی برخوردار باشد؟

معمولاً باید اشیاء یا GameObject ها را بوجود آورده و از بین ببرد و در واقع بر روی آنها مدیریت نماید. در واقع مدل سازی نور، کاراکتر جدید و دشمن در بازی برعهده این قسمت است.
اتصال آنها با Physic ، شبکه و Input . بدین معنا که با ورود Input ،این کاراکتر چگونه به عملکرد خود واقف شود؟ و یا در صورت اجرای Script ، نور چگونه تغییر نماید؟ تمام مدل سازی اینها بر عهده این قسمت است.
شبیه سازی رفتار آبجکت ها. رفتار آبجکت می تواند اسکریپتی و یا به شیوه دیگری باشد.
قابلیت تعریف نوع جدید از اشیاء. منظور از نوع جدید ، Type جدید است. برخی از موتورهای بازی به شما اجازه می دهند که Type جدیدی تعریف کنید. بطوری که بر فرض زمانیکه لامپ از دو قسمت Visual و نور گرافیکی تعریف شده ؛ این دو می توانند در یک Level قرار بگیرند. حال ممکن است لامپی مورد نیاز باشد که صدا هم بدهد. آیا در اینصورت این امکان وجود دارد که یک Type جدید ایجاد کنید که دارای Visual ، نور گرافیکی و صدا باشد؟ در صورت وجود چنین امکانی ، Object model به شما اجازه تعریف Type جدید را خواهد داد.
شناسه یکتا. به هر حال هر GameObject همانند یک Database نیازمند یک شناسه یکتا است. گاهی نیاز است که در اسکریپت ، شما یک درب خاصی را باز کرده و یا یک کاراکتر خاصی را انیمیت کنید. برای دستیابی به چنین اهدافی نیازمند تعریف یک شناسه خاص هستید.

GameObject query تقریباً مهم است. گاهی جهانی را در یک بازی ساخته اید که مایل هستید در آن اتفاقات خاصی رخ دهد. بطور مثال ، انفجاری صورت بگیرد و به شعاع 10 متر ، تأثیر آن بر اشیاء قابل مشاهده باشد. چگونه متوجه وجود GameObject در شعاع ده متری انفجار می شوید؟ این یک نوع query است. بطور مثال یک query فضایی. شاید بخواهید در Level خود همه درختان را بیابید. این یک Query دیگر است. ژانرهای مختلف نیز در این قضیه دخیل است. برخی ژانرها نیازمند Query های خیلی جدی هستند؛ بطوری که در بازی استراتژیک RTS ، انواع Special Query ، فضایی و محیطی ( که محیط را باید بشناسد ) را نیاز دارید. در حالی که در بازی های adventure نیازمند این نوع Query ها نیستیم. زیرا هیچ Object model هم وجود ندارد.

Reference مرتبط با همان GameObject ها است.

امکانات دیگری که در این قسمت موجود است عبارتند از :

پشتیبانی از Finite state machine . حالت های مختلفی برای هر GameObject وجود دارد ؛ آیا شما قادر به تعریف آن هستید؟ تصور کنید کاراکتر با چهار لگد می تواند دربی را بگشاید. این فرایند چگونه هندل شده و سیستم شما چگونه پی می برد که کاراکتر چهار لگد به درب زده است؟ یا چگونه کاراکتر به حالت باز یا بسته درب پی می برد؟
Network Replication . قطعاً زمانی که گیم شما می خواهد از شبکه استفاده کند ؛ بحث Replication نیز بسیار مهم تلقی می گردد. البته GameObject در ژانرهای مختلف ، چگونه می تواند در شبکه پخش شود؟ برخی ژانرها به Latency پایین اما به Replication بالایی نیازمند هستند. حتی در این قسمت باید الگوریتم های پیش بینی شده هم موجود باشد. اما در بازی های ساده adventure یا online شاید خیلی Latency شبکه مهم نباشد.
Object Persistence . در مورد ذخیره شدن آبجکت ها صحبت می کند.
RTTI کمک می کند تا آبجکت ها ، Type خود را بشناسند.
Reflection کمک می کند تا آبجکت ها ، رفتار و دیتای خود را بشناسند. و ایندو عامل باعث ذخیره شدن آبجکت ها می گردد.
Abstract Construction نیز به شما کمک می کند تا آبجکت ها بعداً ساخته شوند.

مبحث مهم دیگر وجود دو مدل آبجکت : Object Centric و Property Centric برای طراحی این Object model است :

در واقع ، گیم های مختلف از ایده های متفاوتی بهره می گیرند.
Object Centric یعنی محور خود شئ. ما در مورد پیاده سازی آن صحبت می کنیم.در مدل های قدیم از Struct استفاده می شد. اما مدلهای جدید ، GameObject نظیر یک میز را همانند یک Class می بیند.
در اینجاست که یک سری ساختار بوجود می آید. در حقیقت جهان گیم را با یک سری درخت های وراثتی نشان می دهند :
در Class Hierarchy ، صحبت بر سر پیاده سازی فرایندی است که طی آن ، بخواهیم با برنامه نویسی نوع های مختلفی از GameObject ایجاد کنیم. این تصویر ، مبین روش ساختار وراثتی است ؛ بطوری که یک Class به نام GameObject تعریف شده و Class های دیگری از آن ارث ببرند. این شیوه سالهای زیادی است که مورد استفاده برخی انجین ها است.

در اینصورت شما کل GameObject هایتان را می توانید با یک ساختار درختی مدل کنید. شکل زیر بیانگر مشکلات موجود در این روش است :

همانطور که در این اسلاید قابل مشاهده است ؛ تعریف Class زیاد شده و کد برنامه نیز افزایش می یابد. اینکه بخواهیم یک Class از قابلیت های مختلفی بهره مند باشد ؛ دشوار است زیرا در پیاده سازی یک ساختار درختی که خود این ساختار ، درون ساختار درختی دیگری واقع شده است؛ با مشکلات متعددی از رویکرد برنامه نویسی مواجه خواهیم بود.یکی از مشکلات موجود در برنامه نویسی ؛ Multile Inheritance است ؛ یعنی وقتی یک Class دارای چند Parent باشد.وابستگی Compile time ، یعنی همه چیز حتی تعریف نوع درخت نیز مستلزم وجود برنامه نویس باشد. خب ، اینکار دشوار است.
روش دیگر که بیانگر معماری مؤلفه گرا است ؛ مسئله را چنین مطرح می کند که GameObject تنها دارای یک ساختار درختی نباشد ؛ بلکه از Composition استفاده کند. در حقیقت ،آنچه که در مدل های انعطاف پذیر پیشنهاد می شود ؛ استفاده از مدلهای Composition است. یعنی GameObject شما دارای یک سریComponent باشد و به مؤلفه هایی تبدیل شود.

Is A به ساختار وراثتی و Has A به ساختار Composition اطلاق می گردد. Composition در برنامه نویسی به معنی ترکیب است. بطور کلی در برنامه نویسی ، دو نوع رابطه وراثت ( inheritance ) و ترکیب وجود دارد.در ترکیب ، یک Class دورن Class دیگری است که از نوع آن نبوده و در واقع ، Child آن محسوب نمی شود . بطور کلی اینها ظرف و مظروفی را تشکیل می دهند ؛ که در این شیوه ، GameObject آن ظرف محسوب می شود که درون خود دارای یکسری Class و به نوعی مؤلفه های مختلف و مرتبط با گرافیک ، صدا و فیزیک است. البته در این حالت ، AI جزو این مؤلفه ها بشمار نمی آید و خود از درخت مجزایی برخوردار است.

حال از رویکرد پیاده سازی به دو صورت می توان به این فرایند نگریست:

خب؛یک سری Pointer از Type های مختلف در GameObject وجود دارد؛ نظیر animation component و sound component که از نظر انعطاف پذیری رضایتی را جلب نمی کند. و همچنین باید Class جدیدی را برای تعریف Type در اختیار داشته باشید.
مشکل این نوع پیاده سازی آن است که در زمان کامپایل ، باید مشخص شود که این Type به چه نوع Type های دیگری اشاره دارد و در حقیقت ؛ در حین برنامه نویسی باید Composition مشخص گردد. مسلم است که اینکار از جمله وظایف برنامه نویس است و Game designer قادر به تعریف Type جدید نیست.لذا یک چنین مدل هایی برای ساخت بازی ، پیشنهاد نمی شوند ؛ زیرا آن انجینی مناسب بشمار می آید که Game designer را قادر به تعریف یک مدل و آبجکت های جدید ساخته و دست او را آزاد بگذارد.
مدل دیگری که کمی مناسب تر است ؛ مدلی است که طبق آن GameObject شما از چندین Generic component برخوردار باشد که از آن ها،انواع Component های دیگر به ارث برسند:

آنچه در این مدل از رویکرد پیاده سازی رخ می دهد ؛ آن است که GameObject دارای آرایه ای از انواع Component ( مؤلفه ) ها است و دیگر برای تعریف Type جدید ، نیازمند تعریف Class جدیدی نیست. می توان همان GameObject را استفاده کرده و تنها Runtime Component را به آن افزود. این مدل مناسبی است که در بسیاری از بازی ها استفاده می شود و بدون نیاز به کامپایل ، می تواند Type جدیدی به آن افزود. این مدل به Game designer اجازه می دهد که در ادیتور نرم افزار خود ، یک Type جدید تعریف کند. گرچه بکارگیری این روش الزاماً برخورداری از Performance نیست.

روش Property Centric Design ، دیگر GameObject را در محوریت قرار نمی دهد؛ بلکه Property از نقش مهمتری برخوردار می گردد. در حقیقت ، در این مدل تمام مؤلفه ها مجزا از یکدیگر لحاظ می شوند و GameObject در این مدل ، تنها یک ID بشمار می آید. این مدل بسیار شبیه Relational Database است که table های مختلفی وجود دارد و در هر table ، شما یک ID اصلی در اختیار دارید. ایجاد ساختار این مدل بر عهده برنامه نویس است که در نهایت Game designer در ادیتور خود یک Objectجدید تعریف کرده و یک ID نیز به آن می دهد و مشخص می کند که این مدل دارای sound، physic و Visual است.

همانطور که مشاهده می کنید ؛ اسلاید زیر مزایای این روش را بازگو می کند:

این مدل جای کمتری را اشغال می کند. هر Type تنها از دیتای مورد نیاز خود برخوردار است. این باعث می شود تا ساخت آن از روی فایل های خارجی راحت تر شود .
مزیت اصلی در مبحث Memory است که دیتاها در یک جا قرار گرفته و دسترسی به آن ها ساده تر خواهد بود.در واقع Cache freindy بودن آن به این مسئله اشاره دارد که وقتی فرضاً قرار است که دیتاهای گرافیکی با هم آپدیت شوند ؛ حقیقتاً داده های مرتبط در حافظه کامپیوتر در کنار یکدیگر قرار دارند . حال آنکه در مدل GameObject این پردازش مستلزم خواندن اطلاعات از موقعیت های مختلف بود که به Cache miss می انجامید.
البته این روش از معایبی نیز برخودار است که شامل سختی در دیباگ و در برقراری ارتباط بین مقادیر Property ، یعنی ارتباط میان آبجکت ها در زمان برخورد و شیوه پاسخگویی آنها پیچیده تر است.

منابع پژوهش :
Object systems” Dough church
Game Engine Architecture” Jason Gregory
Enabling data driven tuning via .. tools” Jeremy chatelaine
Building object systems, features, tradeoff, and pitfull” Alex Duran
A data – driven GameObject system” Scott bilas

Creating a data driven engine” Rob fermier

post

پنجمین دوره مسابقات کشوری بازی های رایانه ای

پنجمین دوره مسابقات کشوری بازی های رایانه ای فدراسیون ورزشهای همگانی در تاریخ 6 الی 11 بهمن ماه سال جاری(1389) در تهران برگزار می گردد.

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

گروه های شرکت کننده در این نمایشگاه :

1- تولید کنندگان بازی های رایانه ای – سی دی های مولتی مدیا(چند رسانه ای) و نرم افزار های کاربردی

2- تولید کنندگان سخت افزار های بازی های رایانه ای

3- فروشندگان تجهیزات و وسایل رایانه (مانیتور، لپ تاپ، کی برد و …) و لوازم جانبی رایانه

4- فروشندگان و تولیدکنندگان تجهیزات و لوازم ورزشی

علاقه مندان برای شرکت در نمایشگاه باید تا تاریخ 89/9/30 درخواست خود را به فدراسیون اعلام نماییند.

جهت اطلاعات بیشتر با شماره تلفن 88404253-021 تماس حاصل فرمایند.

post

فرمانروايان ملت‌ها

فرمانروای ملت ها

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

بیشتر

post

آمادگی بنیاد ملی بازی‌‌های رایانه‌ای برای تولید بازی مختارنامه

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

وی با بیان اینکه با تهیه‌کننده و بنیاد سینمایی فارابی رایزنی لازم صورت گرفته، تصریح کرد: همراه با قسمت‌های بعدی فیلم، بازی آن هم تولید خواهد شد

مینایی ادامه داد: مرکز توسعه و ترویج فعالیت‌های قرآنی هم از تولید این بازی حمایت می‌کند و در راستای اهداف مرکز به صورت مشارکتی ساخته خواهد شد. در عین حال مشغول رایزنی برای جذب حامیان مالی دیگر هستیم.

بهروز مینایی اضافه کرد: بازی فیلم سینمایی «راه آبی ابریشم» و انیمیشمن سینمایی «قلب سیمرغ» در حال ساخت هستند و با علی معلم تهیه‌کننده فیلم «آل» هم برای تولید بازی صحبت شده است.

مدیرعامل بنیاد ملی بازی‌های رایانه‌ای در ادامه اظهار داشت: بنیاد ملی بازی‌های رایانه‌ای آماده است تا پس از رایزنی و طی مقدمات کار، مجموعه تلویزیونی «مختارنامه» را به یک بازی رایانه‌ای فاخر تبدیل کند.

مینایی ابراز علاقه کرد با صدا و سیما و میرباقری درباره این قضیه مذاکره کند.