مسئله‌ای که باید حل می‌کردم
تنظیم صدا نباید با رفتن از منو به حکم فراموش بشه. من یک وضعیت مشترک می‌خواستم که هم حفظ بشه و هم مصرف‌کننده‌های فعال از تغییرش باخبر بشن.
پیاده‌سازی در نسخهٔ فعلی
CardGameSettingsService تنظیم صدا، موسیقی، لرزش و زبان را lazily از PlayerPrefs بارگذاری می‌کنه. SetMusicEnabled و setterهای دیگر فقط وقتی مقدار عوض بشه SaveAndNotify را اجرا می‌کنند.
تصمیم و هزینهٔ طراحی
SettingsChanged یک CardGameSettingsState کامل می‌دهد. مقدار پیش‌فرض زبان فارسی هست و ذخیرهٔ قبلی زبان نگه داشته می‌شود؛ دکمهٔ تغییر زبان تصمیم مرکزی را عوض می‌کنه.
مرزهای فعلی
ذخیرهٔ محلی حساب ابری یا همگام‌سازی بین دستگاه‌ها نیست. وجود گزینهٔ لرزش نیز به‌تنهایی اثبات پیاده‌سازی بازخورد لمسی روی هر دستگاه نیست.
تنظیم مشترک، واکنش مخصوص هر مصرف‌کننده
وقتی بازیکن موسیقی را در منو خاموش می‌کنه و وارد حکم می‌شود، انتظار داره همان ترجیح اعمال بشه. EnsureLoaded تنظیمات را فقط هنگام نیاز از PlayerPrefs می‌خواند و CurrentState چهار مقدار صدا، موسیقی، لرزش و زبان را کنار هم می‌دهد. setterها در صورت برابر بودن مقدار جدید با قبلی زود بازمی‌گردند؛ بنابراین لمس یا refresh رابط که همان مقدار را دوباره می‌فرسته، الزاماً ذخیره و رخداد تازه تولید نمی‌کنه. این رفتار از بازخوردهای غیرضروری می‌کاهد، اما شنونده‌ای که تازه فعال شده باید وضعیت فعلی را هم بخواند و فقط منتظر تغییر آینده نماند.
CardGameAudioManager نمونه‌ای از این مصرف هست: OnEnable به SettingsChanged وصل می‌شود و بلافاصله ApplySettings را با CurrentState اجرا می‌کنه؛ OnDisable اتصال را برمی‌دارد. موسیقی و افکت AudioSource جدا دارن و خاموش بودن صدا در PlaySfx نیز پیش از PlayOneShot بررسی می‌شود. ApplySettings موسیقی غیرفعال را mute می‌کنه و در صورت پخش بودن Pause می‌کنه. این جزئیات مسیر واقعی اعمال ترجیح را توضیح می‌دهند، اما دربارهٔ میزان کیفیت شنیداری، latency یا رفتار همهٔ دستگاه‌ها عددی ارائه نمی‌کنند. وجود تنظیم مشترک با ارزیابی تجربهٔ صوتی یکسان نیست.
SaveAndNotify چهار کلید را می‌نویسد، PlayerPrefs.Save را اجرا می‌کنه و بعد وضعیت کامل را اعلام می‌کنه. ResetToDefaults نیز همهٔ گزینه‌ها را فعال و زبان را فارسی می‌کنه، بدون اینکه به بارگذاری بعدی موکول بشه. در مقابل، مقدار زبان ذخیره‌شده با cast مستقیم خوانده می‌شود و در این سرویس اعتبارسنجی محدودهٔ enum دیده نمی‌شود؛ خواندن ترجیح محلی را نباید تصحیح خودکار همهٔ داده‌های خراب دانست. همچنین گزینهٔ لرزش صرفاً ترجیح را نگه می‌دارد. برای اثبات اجرای haptic باید مصرف‌کنندهٔ سخت‌افزاری و مسیر فراخوانی آن وجود داشته باشد؛ یک بولی ذخیره‌شده آن قابلیت را به‌تنهایی نمی‌سازد.
چیزی که از این مرحله یاد گرفتم
این طراحی برای من تجربهٔ پیوسته ساخت. منو و بازی باید ترجیح یک نفر را بشناسند؛ در عین حال، هر مصرف‌کننده هنوز مسئول هست تغییر وضعیت را درست به صدا یا متن خودش اعمال کنه.
مثال عملی ذخیرهٔ تنظیمات صدا
برای فهم عملی ذخیرهٔ تنظیمات صدا، یک مثال آموزشی را قدم‌به‌قدم دنبال کنیم. بازیکن موسیقی را خاموش می‌کند، صحنه عوض می‌شود و سپس بازی دوباره اجرا می‌شود. پیش از اجرا، وضعیت آغاز را روی کاغذ بنویس؛ مشخص کن چه چیزی می‌تواند تغییر کند و چه چیزی باید ثابت بماند. بعد فقط همین مسیر را اجرا کن. این مثال گزارشی از آمار کاربران یا قابلیت تازهٔ منتشرشدهٔ دلو نیست؛ تمرینی برای روشن کردن تصمیم طراحی همین مطلب است.
خطای رایج و علت آن
اگر هر صحنه مقدار پیش‌فرض خودش را اعمال کند، انتخاب بازیکن از بین می‌رود. این خطا معمولاً وقتی پنهان می‌ماند که فقط مسیر موفق و ظاهر نهایی را ببینیم. برای پیدا کردن علت، آخرین وضعیت درست را از نخستین وضعیت نادرست جدا کن و ببین تغییر دقیقاً در کدام مرز رخ داده است. موسیقی و جلوهٔ صوتی را می‌توان مستقل تنظیم کرد، بدون تغییر قوانین مسابقه. اگر این تفاوت در قرارداد مشخص نباشد، اصلاح یک نشانه ممکن است همان مسئله را در بخش دیگری دوباره ایجاد کند.
چطور نتیجه را بررسی کنیم؟
مقدار ذخیره‌شده، تنظیم کنترل رابط و صدای شنیده‌شده باید با هم یکسان باشند. اجرای یک‌باره برای نتیجه‌گیری کافی نیست؛ یک بار مسیر معمول و بار دیگر همان موقعیت را با ورودی مرزی یا تکرار اقدام بررسی کن. اگر نتیجه فرق دارد، ورودی و شرایط اجرا را همراه خروجی نگه دار تا مقایسه قابل بازسازی باشد. جدول زیر خلاصهٔ مشخصات همین سناریو است و برای ثبت نتیجهٔ بررسی به کار می‌آید.
| بخش بررسی | آنچه باید ثبت شود |
|---|---|
| موقعیت آزمایشی | بازیکن موسیقی را خاموش می‌کند، صحنه عوض می‌شود و سپس بازی دوباره اجرا می‌شود. |
| ریسک اصلی | اگر هر صحنه مقدار پیش‌فرض خودش را اعمال کند، انتخاب بازیکن از بین می‌رود. |
| روش بررسی | مقدار ذخیره‌شده، تنظیم کنترل رابط و صدای شنیده‌شده باید با هم یکسان باشند. |
| مرز نتیجه‌گیری | موسیقی و جلوهٔ صوتی را می‌توان مستقل تنظیم کرد، بدون تغییر قوانین مسابقه. |
پرسش‌های کاربردی دربارهٔ ذخیرهٔ تنظیمات صدا
از کجا شروع کنم؟
از همان موقعیت محدود این مطلب شروع کن: بازیکن موسیقی را خاموش می‌کند، صحنه عوض می‌شود و سپس بازی دوباره اجرا می‌شود. ابتدا نتیجهٔ مورد انتظار را مشخص کن و بعد سراغ پیاده‌سازی یا ابزار برو. وقتی مسیر پایه قابل توضیح و بررسی شد، می‌توان حالت‌های بیشتری اضافه کرد. ساخت همهٔ حالت‌ها از ابتدا، فهم علت خطا را سخت‌تر می‌کند.
چه زمانی می‌توانم بگویم این بخش درست کار می‌کند؟
زمانی که رفتار در موقعیت تعریف‌شده با قرارداد سازگار باشد و محدودیت‌های آن روشن بمانند. مقدار ذخیره‌شده، تنظیم کنترل رابط و صدای شنیده‌شده باید با هم یکسان باشند. موفقیت در این آزمون دربارهٔ همان سناریو شاهد می‌دهد؛ از آن نمی‌توان بدون بررسی دربارهٔ همهٔ دستگاه‌ها، همهٔ قوانین محلی یا همهٔ حجم‌های داده نتیجه گرفت. موسیقی و جلوهٔ صوتی را می‌توان مستقل تنظیم کرد، بدون تغییر قوانین مسابقه.
برای ادامهٔ همین موضوع، هستهٔ مشترک دلو؛ یک میز برای چند بازی و بازی دلو را ببین. زمینهٔ ساخت این پروژه‌ها و معرفی سازنده در صفحهٔ کیان پاک نعمت آمده است.
