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