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