Google Playground چیست؟ ساخت بازی با پرامپت و محدودیت‌های دسترسی

آخرین بررسی منابع: ۲۱ اکتبر ۲۰۲۶

Google Playground چیست و چه مسئله‌ای را حل می‌کند؟

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

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

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

شرایط دسترسی، نسخه رایگان و وضعیت استفاده در ایران

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

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

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

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

درخواست «یک بازی عالی بساز» تصمیم‌های اصلی را به مدل واگذار می‌کند. برای نتیجه قابل سنجش، ابتدا بنویسید بازیکن چه کاری انجام می‌دهد و چرا باید دوباره بازی کند. در نسخه اول، یک مکانیک یا قانون اصلی کافی است؛ مثلاً انتخاب مسیر درست، جورکردن دو کارت یا عبور از چند مانع ساده.

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

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

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

روش پیشنهادی ساخت بازی؛ از نسخه ساده تا اصلاح کنترل‌ها

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

1. نمونه اول: فقط یک صحنه، یک هدف و یک مسیر شروع مجدد بخواهید.
2. بررسی قانون: ببینید شرط برد و باخت دقیقاً همان چیزی است که تعریف کرده‌اید.
3. اصلاح کنترل: واکنش لمس یا کلید را پیش از افزودن تزئینات بررسی کنید.
4. بازخورد روشن: تغییر امتیاز، برخورد و پایان بازی باید قابل تشخیص باشد.
5. آزمون دوباره: پس از هر اصلاح، مسیرهای قبلاً سالم را مجدد امتحان کنید.
6. بازبینی نهایی: از یک نفر که بریف را نخوانده بخواهید بازی را شروع کند.

گزارش خوب به مدل شامل رفتار مشاهده‌شده، انتظار شما و یک راه بازتولید است. مثلاً بنویسید: «بعد از برخورد سوم، صفحه پایان دیده می‌شود اما حرکت شخصیت ادامه دارد. در حالت پایان، حرکت و افزایش امتیاز متوقف شود و شروع دوباره همه متغیرها را بازنشانی کند.» این درخواست از «باگ‌ها را درست کن» دقیق‌تر است.

سه پرامپت آماده برای شروع و اصلاح بازی

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

پرامپت اول: بازی کوتاه جمع‌کردن اشیا

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

پرامپت دوم: اصلاح تجربه موبایل

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

پرامپت سوم: بازخورد و شروع دوباره

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

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

چک‌لیست تست بازی؛ چه چیزی را قبل از اشتراک‌گذاری بررسی کنیم؟

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

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

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

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

دریافت سورس و استفاده روی سایت؛ چه مراحلی باقی می‌ماند؟

مرکز راهنما دریافت ZIP شامل HTML، JavaScript، CSS و دارایی‌های تولیدشده را توضیح می‌دهد. این امکان برای ادامه توسعه مهم است، اما خروجی را پیش از انتشار روی سایت خودتان بازبینی کنید. دریافت فایل را با انتقال بی‌دردسر همه خدمات و قابلیت‌های پلتفرم یکسان ندانید.

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

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

اشتراک‌گذاری و کاربرد تجاری؛ از نمونه اولیه چه انتظاری داشته باشیم؟

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

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

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

خطاها و محدودیت‌ها را چطور بررسی کنیم؟

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

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

درباره Unity Spark هم باید زمان‌بندی را دقیق نوشت: صفحه رسمی بررسی‌شده فهرست انتظار دارد. برنامه آینده یا نمونه نمایشی را قابلیت عمومی آماده تحویل فرض نکنید. برای پروژه‌ای با موعد مشخص، فقط روی امکاناتی حساب کنید که دسترسی و خروجی آن‌ها را عملاً تأیید کرده‌اید.

تصویرسازی مفهومی کنترل دسترسی و اشتراک‌گذاری بازی؛ تصویرسازی اختصاصی با هوش مصنوعی، نه اسکرین‌شات ابزار.

برای شروع پروژه خودتان چه چیزهایی آماده کنید؟

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

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

پرسش‌های متداول

آیا Google Playground در ایران فعال است؟

در زمان بررسی، راهنمای رسمی دسترسی را برای افراد ۱۸ سال به بالای آمریکا اعلام می‌کند. دسترسی رسمی ایران تأیید نشده و بازشدن سایت به‌تنهایی نشانه فعال بودن ساخت بازی نیست.

آیا ساخت بازی در Playground رایگان است؟

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

آیا برای شروع باید برنامه‌نویسی بلد باشم؟

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

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

بله؛ مرکز راهنما دریافت فایل ZIP شامل HTML، JavaScript، CSS و فایل‌های تولیدشده را توضیح می‌دهد. قبل از استفاده روی سایت خودتان، وابستگی‌ها، امنیت و حقوق فایل‌ها را بررسی کنید.

بهترین پرامپت برای ساخت اولین بازی چیست؟

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

آیا Unity Spark برای همه در دسترس است؟

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

آیا بازی ساخته‌شده حتماً روی موبایل خوب کار می‌کند؟

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

روش تهیه این راهنما

اطلاعات محصول با خبر رسمی گوگل، مرکز راهنمای Playground و صفحه Unity Spark در ۲۱ اکتبر ۲۰۲۶ تطبیق داده شد. پرامپت‌ها و چک‌لیست‌ها پیشنهاد آموزشی آونا هستند؛ ورود با حساب واجد شرایط، اجرای بازی یا ارزیابی عملی عملکرد انجام نشده است. چهار تصویر اختصاصی با هوش مصنوعی ساخته شده‌اند و اسکرین‌شات محصول نیستند.