یک سؤال برای نمونه انتخاب کن
نمونهٔ اولیه باید به سؤال طراحی جواب بدهد، نه محصول نهایی را تقلید کنه. در بازی کارتی شاید سؤال جذاب بودن انتخاب میان دو کارت مجاز باشد. تصویر موقت و چرخهٔ کوتاه کافی هست اگر تصمیم مورد بررسی را حفظ کنه.
برای بازی کارتی، سؤال می‌تواند این باشد: انتخاب بین دو کارت قانونی واقعاً فکر کردن می‌خواهد؟ اگر پاسخ این هست، نمونه باید دو گزینه، پیامد هر انتخاب و فرصت یک دور دیگر را داشته باشد. صفحهٔ ورود، حساب کاربری و ده مدل پشت کارت به این سؤال جواب نمی‌دهدند. اما اگر اطلاعات لازم برای تصمیم را حذف کنی، حتی نمونهٔ ساده هم سؤال را درست نمی‌سنجد. ساده‌سازی یعنی کنار گذاشتن چیزهای بی‌ربط، نه حذف زمینه‌ای که انتخاب را معنی‌دار می‌کنه. سؤال را بالای فهرست کار بنویس تا معیار افزودن هر جزء معلوم بماند.
آنچه تصمیم را عوض می‌کنه نگه دار
انتخاب میان دو کارت را با مستطیل و عنوان ساده نمونه‌سازی کن. فرد انتخاب کنه و بده‌بستان دیده‌شده را توضیح دهد. اگر تفاوت معناداری نیست، تصویر بیشتر به‌تنهایی آن را نمی‌سازد. تصمیم یا پیامد را عوض و دوباره امتحان کن. تمرکز را نگه داری تا درس دربارهٔ مکانیک باشد، نه نظر دربارهٔ پرداخت بصری موقت.
در مشاهده، فقط نپرس «خوب بود؟». ببین فرد به کدوم اطلاعات نگاه می‌کنه، کجا مکث داره و آیا نتیجه را به انتخاب خود نسبت می‌دهد. بعد بپرس انتظارش از کارت دیگر چه بوده. اگر بدون فکر همیشه یک گزینه را می‌زند، شاید یکی آشکارا بهتر هست یا شاید تفاوت گزینه‌ها فهمیده نمی‌شود. این دو علت اصلاح یکسان ندارند. چند مشاهده را در کنار فرض اولیه بنویس و دربارهٔ نیاز به تغییر تصمیم بگیر؛ نمونهٔ کوچک قرار نیست با چند بازی، محبوبیت آیندهٔ کل محصول را اثبات کنه.
نتیجهٔ آزمایش را به تغییر وصل کن
برای دور بعد فقط یک متغیر مهم را عوض کن، مثلاً هزینهٔ یک کارت یا وضوح پیامد اون. با تغییر هم‌زمان قانون، تصویر و سرعت، فهمیدن دلیل تفاوت دشوار می‌شود. نسخهٔ قبلی را نگه دار و بنویس از هر نسخه چه یاد گرفتی. اگر سؤال پاسخ گرفت، لازم نیست نمونه را تا بی‌نهایت تزئین کنی؛ می‌توانی آن را پایهٔ یک مسیر کامل‌تر کنی یا ایده را کنار بگذاری. کنار گذاشتن نمونه‌ای که یک فرض ضعیف را آشکار کرده، شکست ساخت نیست؛ همان اطلاعاتی هست که آزمایش باید فراهم می‌کرد.
مطالعهٔ بیشتر: Unity: Introduction to scenes
برای یک مثال مرتبط، هستهٔ مشترک دلو؛ یک میز برای چند بازی را هم بخون.
مثال عملی نمونهٔ اولیهٔ بازی
برای فهم عملی نمونهٔ اولیهٔ بازی، یک مثال آموزشی را قدم‌به‌قدم دنبال کنیم. برای بررسی جذابیت کشیدن کارت، ابتدا فقط دست، حرکت و نتیجه را بساز. پیش از اجرا، وضعیت آغاز را روی کاغذ بنویس؛ مشخص کن چه چیزی می‌تواند تغییر کند و چه چیزی باید ثابت بماند. بعد فقط همین مسیر را اجرا کن. این مثال گزارشی از آمار کاربران یا قابلیت تازهٔ منتشرشدهٔ دلو نیست؛ تمرینی برای روشن کردن تصمیم طراحی همین مطلب است.
خطای رایج و علت آن
فروشگاه و منوی کامل پیش از آزمودن حلقهٔ اصلی، زمان را صرف فرضیهٔ اثبات‌نشده می‌کنند. این خطا معمولاً وقتی پنهان می‌ماند که فقط مسیر موفق و ظاهر نهایی را ببینیم. برای پیدا کردن علت، آخرین وضعیت درست را از نخستین وضعیت نادرست جدا کن و ببین تغییر دقیقاً در کدام مرز رخ داده است. پروتوتایپ باید یک سؤال طراحی را پاسخ دهد و لازم نیست همهٔ ویژگی‌های محصول را داشته باشد. اگر این تفاوت در قرارداد مشخص نباشد، اصلاح یک نشانه ممکن است همان مسئله را در بخش دیگری دوباره ایجاد کند.
چطور نتیجه را بررسی کنیم؟
از بازیکن بخواه چند دور انجام دهد و رفتار واقعی او را مشاهده کن. اجرای یک‌باره برای نتیجه‌گیری کافی نیست؛ یک بار مسیر معمول و بار دیگر همان موقعیت را با ورودی مرزی یا تکرار اقدام بررسی کن. اگر نتیجه فرق دارد، ورودی و شرایط اجرا را همراه خروجی نگه دار تا مقایسه قابل بازسازی باشد. جدول زیر خلاصهٔ مشخصات همین سناریو است و برای ثبت نتیجهٔ بررسی به کار می‌آید.
| بخش بررسی | آنچه باید ثبت شود |
|---|---|
| موقعیت آزمایشی | برای بررسی جذابیت کشیدن کارت، ابتدا فقط دست، حرکت و نتیجه را بساز. |
| ریسک اصلی | فروشگاه و منوی کامل پیش از آزمودن حلقهٔ اصلی، زمان را صرف فرضیهٔ اثبات‌نشده می‌کنند. |
| روش بررسی | از بازیکن بخواه چند دور انجام دهد و رفتار واقعی او را مشاهده کن. |
| مرز نتیجه‌گیری | پروتوتایپ باید یک سؤال طراحی را پاسخ دهد و لازم نیست همهٔ ویژگی‌های محصول را داشته باشد. |
پرسش‌های کاربردی دربارهٔ نمونهٔ اولیهٔ بازی
از کجا شروع کنم؟
از همان موقعیت محدود این مطلب شروع کن: برای بررسی جذابیت کشیدن کارت، ابتدا فقط دست، حرکت و نتیجه را بساز. ابتدا نتیجهٔ مورد انتظار را مشخص کن و بعد سراغ پیاده‌سازی یا ابزار برو. وقتی مسیر پایه قابل توضیح و بررسی شد، می‌توان حالت‌های بیشتری اضافه کرد. ساخت همهٔ حالت‌ها از ابتدا، فهم علت خطا را سخت‌تر می‌کند.
چه زمانی می‌توانم بگویم این بخش درست کار می‌کند؟
زمانی که رفتار در موقعیت تعریف‌شده با قرارداد سازگار باشد و محدودیت‌های آن روشن بمانند. از بازیکن بخواه چند دور انجام دهد و رفتار واقعی او را مشاهده کن. موفقیت در این آزمون دربارهٔ همان سناریو شاهد می‌دهد؛ از آن نمی‌توان بدون بررسی دربارهٔ همهٔ دستگاه‌ها، همهٔ قوانین محلی یا همهٔ حجم‌های داده نتیجه گرفت. پروتوتایپ باید یک سؤال طراحی را پاسخ دهد و لازم نیست همهٔ ویژگی‌های محصول را داشته باشد.
برای ادامهٔ همین موضوع، قانون هر بازی کجا زندگی می‌کند؟ را ببین. زمینهٔ ساخت این پروژه‌ها و معرفی سازنده در صفحهٔ کیان پاک نعمت آمده است.
