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