خانه محصولات اشتراک ها مقاله ها راهکارها درباره ما ورود به حساب درخواست مشاوره
MODIRAM / JOURNAL

بازی‌سازی با Playground گوگل؛ از چند جمله تا قوانینی که باید امتحان شوند

Playground گوگل بازی را از توضیح متنی می‌سازد. با یک مثال فرضی بررسی می‌کنیم چرا قانون برد، بازخورد و شروع دوباره باید جدا از ظاهر بازی سنجیده شوند.

تاریخ انتشار1405/07/21 07:50 زمان مطالعه6 دقیقه
بازی‌سازی با Playground گوگل؛ از چند جمله تا قوانینی که باید امتحان شوند
MODIRAM EDITORIALهوش مصنوعی

«یک ماشین کوچک باید بسته را به فانوس دریایی برساند.» این توصیف برای تصورکردن یک بازی کافی است. اما برای ساختنش، یک سؤال باقی می‌ماند: اگر ماشین بدون برداشتن بسته به مقصد برسد، باید برنده شود؟ همین فاصله میان تصویر ذهنی و قانون دقیق، نقطه خوبی برای شناخت Playground است؛ ابزار تازه گوگل که می‌خواهد ایده بازی را از راه گفت‌وگو به چیزی قابل اجرا تبدیل کند.

گوگل در ۷ اکتبر ۲۰۲۶ Playground را به‌عنوان یک سکوی آزمایشی معرفی کرد. طبق توضیح شرکت، می‌توان با متن بازی ساخت، آن را امتحان کرد و با درخواست‌های بعدی، قوانین یا محیطش را تغییر داد. عرضه اولیه برای کاربران ۱۸ سال به بالای آمریکا اعلام شده و دسترسی ساخت به سطح اشتراک Google AI وابسته است. بنابراین این معرفی را نباید وعده دسترسی عمومی از ایران دانست. معرفی رسمی Playground

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

صحنه دیده می‌شود؛ قانون باید خودش را در بازی نشان بدهد

در گزارش ۹ اکتبر TechRadar، اریک هال شوارتز دو بازی ساخته است: یکی با ایده‌ای ساده و دیگری با توضیحی مفصل‌تر. او از سرعت تبدیل ایده به محیط قابل‌بازی و بازتاب بعضی جزئیات درخواستش استقبال می‌کند، اما مشکلات منطق بازی و روایت را هم شرح می‌دهد. این تجربه محدود، نه آزمون مقایسه‌ای جامع است و نه مدرکی درباره کیفیت همه خروجی‌ها. تاریخ این بررسی نیز با تاریخ معرفی ۷ اکتبر فرق دارد. گزارش دست‌اول TechRadar

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

در توضیح ساده فنی، بازی باید وضعیت فعلی را نگه دارد: بسته برداشته شده یا نه، ماشین کجاست و مرحله تمام شده یا هنوز ادامه دارد. حرکت بازیکن می‌تواند این وضعیت را تغییر دهد. اگر شرط پایان فقط «رسیدن به مقصد» باشد، حضور بسته هیچ نقشی ندارد؛ حتی اگر داستان بازی درباره تحویل بسته حرف بزند. این توضیح درباره منطق نمونه ماست و ادعایی درباره پیاده‌سازی داخلی Playground نیست.

پس شرح دقیق‌تر ایده چنین می‌شود: «دروازه فقط وقتی باز شود که ماشین بسته را برداشته باشد؛ پس از عبور از دروازه، مرحله تمام شود.» این جمله هنوز همه طراحی را تعیین نمی‌کند، اما رابطه‌ای قابل بررسی می‌سازد. حالا به‌جای داوری از روی زیبایی صحنه، می‌توانیم عمداً بدون بسته به دروازه برسیم و نتیجه را ببینیم.

از راهی برویم که سازنده انتظارش را نداشته است

تصویرسازی مفهومی ماشین بازی، بسته و دروازه برای بررسی شرط رسیدن به مقصد
تصویرسازی مفهومی: وجود بسته در صحنه کافی نیست؛ قانون بازی باید برداشتن آن را به بازشدن مسیر وصل کند.

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

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

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

اصلاح کوچک هم ارزش بررسی دوباره دارد. اگر فقط درخواست کنیم مسیر کوتاه‌تر شود، ممکن است بسته از مسیر معمول بازیکن دور بماند. در مثال ما، بهتر است پس از تغییر مسیر همان دو حالت با بسته و بدون بسته را تکرار کنیم. از این مثال نمی‌توان نتیجه گرفت که Playground حتماً چنین اشتباهی می‌کند؛ نکته این است که ظاهر بهترِ یک نسخه، به‌تنهایی حفظ رفتار قبلی را ثابت نمی‌کند.

اشتراک‌گذاری امروز با امکانات وعده‌داده‌شده یکی نیست

گوگل برای خروجی Playground سه انتخاب توضیح می‌دهد: خصوصی نگه‌داشتن، فرستادن لینک و انتشار در گالری عمومی. بازی‌ها در مرورگر اجرا می‌شوند و بعضی سبک‌ها از بازی چندنفره پشتیبانی می‌کنند. این توضیح را نباید به پشتیبانی چندنفره در هر بازی یا امکان انتشار در هر فروشگاه نرم‌افزاری تعمیم داد. روش‌های بازی و اشتراک‌گذاری در معرفی گوگل

هم‌زمان، Unity در اطلاعیه ۷ اکتبر از برنامه ارائه تجربه پیشرفته‌تر Unity Spark در ادامه سال خبر داده است. امکانات سه‌بعدی پیشرفته‌تر در آن اطلاعیه بخشی از برنامه آینده‌اند. صفحه جاری Spark نیز هنگام بررسی ۱۳ اکتبر همچنان عبارت «به‌زودی» و فهرست انتظار را نشان می‌دهد؛ وجود بازی‌های نمایشی به معنی دسترسی عمومی به ابزار ساخت نیست. اطلاعیه همکاری Unity و گوگل و صفحه فعلی Unity Spark

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

یک بار بازی‌کردنِ کسی که توضیح ما را نشنیده است

در پایانِ نمونه فرضی، بازی را به دوستی می‌دهیم که متن اولیه را ندیده است. از او نمی‌خواهیم تعریف کند که ساخت بازی چقدر سریع بوده؛ فقط نگاه می‌کنیم چه می‌کند. اگر مستقیم به فانوس برود و پشت دروازه بماند، همین مکث اطلاعات دارد: شاید بسته خوب دیده نمی‌شود، شاید هدف روشن نیست یا شاید نشانه بسته‌بودن دروازه معنایی برای او ندارد.

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

هر دو تصویر با هوش مصنوعی ساخته شده‌اند و تصویرسازی مفهومی‌اند؛ نمای واقعی Playground یا نتیجه آزمون محصول نیستند.

منابع

M
درباره نویسنده

تیم تحریریه مدیرم

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

همه مقاله‌ها ↗
گفتگو درباره این مطلب

نظر شما چیست؟

نظر شما برای ما ارزشمند استدیدگاه شما پس از بررسی نمایش داده می‌شود.
امتیاز شما
NEXT STEP / YOUR PROJECT

این مسئله در کسب‌وکار
شما هم واقعی است؟

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

شروع گفتگو ↗