نگاهی به تکنیک های ذخیره و بازیابی فایل ها در بازی های کامپیوتری
نویسنده: مهندس سید علی الحسینی
* همزمان با گسترش روز افزون صنعت بازی و گرایش بیشتر افراد در سنین و گروه های مختلف به استفاده از این محصولات دیجیتالی، در کامپیوترها و کنسول ها، بازی ها نیز از نظر کمی و کیفی رشد قابل توجهی یافته اند، به گونه ای که در حال حاضر شباهت صحنه های برخی بازی ها به واقعیت بسیار بالا بوده و از این نظر نمی توان مجموعه بازی های ساخته شده در چند سال اخیر را با محصولات تولیدی یک دهه قبل مقایسه کرد. اگر چه در این میان شاید نتوان رابطه مشخص و منطقی بین میزان واقع گرایی و زیبایی و جذابیت صحنه ها، تصاویر، مدل ها و جلوه های بازی ها، با حجم محتوای آنها یافت، ولی در هر صورت می توان چنین گفت که برای داشتن بازی های زیباتر، باید از داده های بیشتری هم بهره برد که به همین میزان بر حجم بازی می افزایند.
این بهره گیری از داده های بیشتر، در اغلب اوقات خود را به صورت افزایش حجم بازی و بعضاً عرضه آن بر روی DVD نمایان می کند، چیزی که این روزها بسیار مرسوم شده و در حال تبدیل شدن به یک عادت می باشد، به این معنی که عموم کاربران بازی ها نیز تصور می کنند با افزایش حجم بازی (تعداد CDهای بیشتر و یا عرضه بازی روی DVD)، قطعاً کیفیت بازی نیز افزایش خواهد یافت (اگر چه این مسئله در حالت کلی به هیچ وجه صحت ندارد).
با ذکر این مقدمه، در این نوشتار قصد داریم یکی از جنبه های تقریباً پنهان روند توسعه بازی، یعنی فعالیت های فایلی (بازیابی و حتی ذخیره فایل ها) را بررسی کنیم. بخاطر داشته باشید که ما قرار نیست دستورات برنامه نویسی یا الگوریتم های ویژه ای را معرفی کنیم، بلکه بیشتر قصد داریم با فرآیند کلی بازیابی و ذخیره فایل ها در بازی ها (بعنوان نرم افزارهایی بسیاربزرگ و پرحجم) آشنا شویم.
البته در مرحله اول بهتر است راه های گوناگون بکار رفته در روند بازیابی محتوای بازی ها را بررسی کنیم. این محتوا که بصورت فایل های برنامه ظاهر می شود، می تواند در برگیرنده مدل ها، تصاویر، منوها، بافت ها، انیمیشن ها، صداها و یا موسیقی ها باشد.
فیلم های بازی هم که این روزها بخش بزرگی از این محتوا را تشکیل می دهند. ضمن اینکه شاید در وهله اول، ساده ترین راهی که برای بار گذاری این فایل ها به نظر می رسد، خواندن یکباره تمامی آنها در زمان شروع بازی باشد. اما باید تاکید نمود که این روند کم کم در حال منسوخ شدن است، زیرا باعث کند شدن شروع بازی و افزایش زمان انتظار برای بازیکن می شود، و گاهی نیز می تواند با اشتغال کردن تمامی فضای حافظه، موجب بروز خطاهای حافظه ای شود.
البته یک برنامه نویس، روش خود را با توجه به نوع وسبک بازی، توانایی خود و سایر ملاحظات فنی و غیرفنی انتخاب می کند و در صورت مناسب بودن حجم محتوای فایل های بازی، این روش هنوز هم می تواند کارایی خوبی داشته باشد.
ضمناً توجه شما را به این نکته جلب می کنیم، که در اغلب مواقع، تصاویر و یا اطلاعاتی که در هنگام شروع بازی ها (که برخی مواقع صبر و حوصله کاربر را لبریز می کند)، به کاربر نشان داده می شوند، معمولاً راهی برای جلب توجه کاربر و در نتیجه داشتن فرصت برای انجام عملیات طولانی، زمانبر و خسته کننده بار گذاری فایل ها در پشت پرده می باشد. البته در برخی موارد نیز بجای تصاویر ثابت، از قطعات انیمیشنی ساده استفاده می شود. علاوه بر این می توان بجای خواندن یکباره کلیه فایل ها (که ممکن است زمان زیادی صرف کند)، این فرآیند را در چند مرحله در زمان شروع بازی انجام داد. این کاری است که احتمالاً در بسیاری از بازی ها دیده اید (یعنی مقداری از فایل ها خوانده می شوند، سپس تصویر جدیدی ظاهر شده و از شما درخواست می کند کلیدی را بزنید، سپس دوباره فایل های بیشتری خوانده می شوند. این عملیات ممکن است به اشکال مختلف ادامه یابد تا اینکه کل فایل های لازم وارد حافظه شوند). البته خواندن فیلم (انیمیشن ) ابتدای بازی، معمولاً توسط الگوریتم های پیچیده جریانی (Stream) انجام می گیرد و به همین جهت زمان زیادی برای بارگذاری و پخش آن صرف نمی شود، به این ترتیب که بجای خواندن کل فایل انیمیشن (که اغلب حجم بسیار بالایی دارد)، مقدار کمی از آن خوانده و پخش می شود، و در همین زمان قسمت بعدی فایل وارد حافظه شده و در یک بافر موقتی جای می گیرد. پس از اتمام پخش قسمت اول، قسمت دوم از بافر وارد حافظه اصلی شده و پخش می گردد ؛این روند تا پخش کل انیمیشن ادامه می یابد.
گرچه استفاده از رویکرد جریانی (یعنی خواندن بخشی از فایل و نمایش بخشی دیگر در همان زمان) برای سایر انواع فایل های بازی (همچون مدل ها و تصاویر)، کاربرد ندارد، ولی برخی APIها همچون DirectMusic امکان بهره گیری از این تکنیک را جهت تسریع عملیات بار گذاری موسیقی دارند. API قدرتمند DirectShow (که البته درDirectX 10 مجدداً از API جدا شده است) نیز امکان بهره گیری از این تکنیک را ارائه می کند و به همین جهت مورد استفاده بسیاری از بازی ها، برای پخش قطعات کلیپ و فیلم قرار می گیرد.
* اما انتقال کلیه محتویات فایل های بازی در زمان شروع، به درون حافظه (حافظه اصلی، حافظه سریع و محدود کارت گرافیکی، حافظه محلی، و یا حافظه AGP)، با توجه به رشد سریع حجم فایل ها، امروزه در بسیاری از موارد، عملی و منطقی نمی باشد. اگر سبک بازی و همچنین سیستم های نهایی مورد نظر برای اجرای بازی، نقش مهمی در تعیین تکنیک بکار رفته دارند، ولی رویکردی که در حال حاضر بسیار رواج یافته است، بار گذاری غیرپیوسته محتویات فایل های بازی می باشد، به گونه ای که در هر زمان صرفاً محتوای لازم برای نمایش هر صحنه بار گذاری شده و پس از اتمام هر صحنه، بیشتر این فایل ها از حافظه خارج می شوند تا امکان بار گذاری فایل های جدید برای سایر صحنه ها فراهم شود.
این رویکرد می تواند تضمین کننده افزایش سرعت بار گذاری و حتی اجرا باشد، زیرا در صورت مدیریت صحیح حافظه، در هر لحظه کمترین میزان ضروری از حافظه اشغال بوده و امکان تغییر مکان سریع محتوای هنری (بعنوان مثال، انتقال بافت های لازم برای رندر صحنه ها از RAM به حافظه قابل دسترسی پردازنده گرافیکی)، وجود خواهد داشت.در عین حال پیاده سازی این روش دشوار بوده و احتیاج به درک بالایی از ساختار حافظه، آشنایی با تکنیک های نوین مدیریت حافظه و بهره گیری از منابع مدیریت شده (Managed Resource)دارد. منابع مدیریت شده، گونه نسبتاً جدیدی از منابع می باشند که Direct3D نیز بخوبی از آنها پشتیبانی می کند. این منابع که می توانند شامل بافت ها، مدل ها و تصاویر مختلف باشند، قابلیت انتقال بین بخش های مختلف حافظه را دارا بوده و کاربرد مناسبی از نظر بازیابی دارند. البته استفاده از این رویکرد بازیابی فایل ها در کلیه انواع بازی ها، قابل ا ستفاده نمی باشد.
بعنوان مثال، در یک بازی ورزشی مانند فوتبال که تقریباً تمامی مدل ها، تصاویر و انیمیشن ها در یک صحنه واحد (زمین بازی ) به طور همزمان به نمایش در می آیند، نمی توان این روش را با کارآیی بالایی بکار برد. در عوض در بازی های ماجرایی و یا مرحله ای، استفاده از این روش آسانتر بوده و موجب بهبود عملکرد اجرایی برنامه خواهد شد. همچنین همواره بخاطر داشته باشید که عملیات های فایلی (یعنی خواندن و نوشتن)، بصورت بالقوه کند هستند، زیرا فعالیت دیسک سخت (که عمدتاً بصورت مکانیکی می باشد)، علی رغم تمامی پیشرفت های صورت گرفته، هنوز نسبت به فعالیت های انجام گرفته در حوزه حافظه RAM، بسیار کند محسوب می شود، در نتیجه برنامه نویسان سعی می کنند تا حد امکان از بار گذاری فایل ها در حین نمایش صحنه ها، اجتناب کنند. البته در برخی موارد، به ناچار بار گذاری تصاویر بافتی در زمان نمایش صحنه ها، ضرورت می یابد (مثلاً خواندن بافت های کوچکتر و یا بزرگتر برای استفاده در تکنیک Mipmap) که این مسئله می تواند موجب کاهش سرعت اجرای برنامه و حتی در مواردی توقف چند لحظه ای اجرا شود.
باید توجه داشته باشید که حجم فایل های موجود بر روی دیسک، ممکن است در حافظه اجرایی برنامه به چندین برابر برسد، و این مسئله ای است که می تواند باعث کاهش سرعت اجرایی و همچنین افزایش احتمال بروز خطا در روند اجرای صحیح برنامه شود. همچنین هنوز هم بهتر است برای تست روند خواندن فایل ها در بازی خود، از سیستم های نسبتاً قدیمی تر بهره ببرید، زیرا اختلاف زمان بار گذاری فایل ها در دیسک های سخت جدید و قدیم (که فن آوری هایی مانند SATA را ندارند)، ممکن است بسیار قابل توجه باشد، در این صورت احتمالاً باید روند بار گذاری را به شکل هوشمندانه ای در سیستم های مختلف مدیریت کنید تا کاربران برنامه شما بتوانند با خیال راحت برنامه را در طیف وسیعی از سیستم ها اجرا کنند.
* اما فعالیت های فایلی یک بازی، تنها به عملیات خواندن فایل ها محدود نمی شود، و تقریباً تمامی انواع بازی ها احتیاج دارند داده های خاصی را جهت ذخیره (و بازیابی بعدی) بر روی فایل ها بنویسند. این فرآیند نوشتن، می تواند به سادگی نوشتن امتیازات بازیکنان، گزینه های مختلف بازی و یا به پیچیدگی نوشتن مراحل طی شده یک بازیکن و یا ثبت صحنه های پخش شده در یک بازی ورزشی باشد. البته نکته مهم در هر صورت بدست آودن ساختار مناسب برای ذخیره داده ها می باشد، زیرا در این صورت شما می توانید صرفاً با پر کردن چند ساختار، داده های مورد نظر خود را در فایل ها بنویسید.
در هر حال یادتان باشد که تا حد امکان از انجام فعالیتهای دیسکی (بخصوص نوشتن ) در حین رندر صحنه ها خودداری کنید. در واقع اگر می خواهید مراحل طی شده و دارایی های بازیکن (تعداد جان ها «تعداد زندگی هایی که می تواند داشته باشد»، تعداد اشیاء گران قیمت جمع آوری شده، امتیازات و ...) را در طول یک بازی ماجرایی ثبت کنید، بهتر است آنها را همچون بسیاری از بازی های معروف این کار، در نقاط خاصی که اصطلاحاً Check Point نامیده می شوند، انجام دهید تا بتوانید با نمایش یک تصویر کوچک و توقف چند لحظه ای بازی، کاربر را از توجه به فعالیت دیسک باز دارید.
بخاطر داشته باشید که پس از اتمام کارتان با یک فایل، حتماً آن را ببندید تا از اتلاف حافظه و فعالیت اضافه دیسک سخت، جلوگیری شود.
ناگفته نماند، برخی از بازی ها نیز امکان ثبت تعداد نامحدودی فایل های ذخیره (Save) را به بازیکن می دهند. برای مدیریت بهتر فایل های ذخیره و سهولت در روند بازیابی (Load) آنها، می توانید از یک فایل کوچک برای ثبت کلیه فایل های ذخیره و داده های مربوط به آنها (بعنوان مثال، زمان و تاریخ ذخیره و یا اطلاعاتی در رابطه با موقعیت بازیکن در هنگام ذخیره بازی)، استفاده کنید. حتی می توانید امکان نامگذاری فایل ذخیره را نیز به بازیکن بدهید. به این ترتیب باید فایل های ذخیره را در پوشه ای جداگانه نگه داری کنید و ضمن رعایت مسائلی امنیتی، در هنگام بار گذاری فایل ها نیز نام آنها را با نام ثبت شده در فایل راهنمای ذخیره، تطبیق دهید.
* در انتها بد نیست چند نکته اساسی و مهم در کار با فایل ها را مرور کنیم. تقریباً در هر حالتی، کار با فایل های باینری، بهتر از کار با فایل های متنی می باشد. زیرا علاوه بر عدم امکان مشاهده و تغییر آنها توسط کاربران عادی، خواندن و همچنین نوشتن آنها نیز به مراتب سریعتر است (مثلاً یک عدد اعشاری در حالت متنی می تواند به حدود 10 تا 14بایت فضا احتیاج داشته باشد، در حالیکه همین عدد در حالت باینری، تنها در 4 بایت قابل ذخیره است).
در واقع هر چه تعداد عملیات های فایلی کمتر باشد، سرعت برنامه بیشتر خواهد بود، در نتیجه تا حد امکان دستورات خواندن و نوشتن فایل را کاهش دهید (مثلاً بهتر است بجای ده بار نوشتن مجموعه اعداد اعشاری، آنها را در یک ساختار ذخیره کرده و ساختار مورد نظر را با یک دستور بنویسید. به این ترتیب خواندن فایل نیز با استفاده از همین ساختار، به مراتب سریعتر انجام خواهد شد). همچنین سعی کنید از نامگذاری فایل ها، با اسامی خیلی طولانی پرهیز کنید، زیرا این کار می تواند موجب بروز خطا در فرآیند بار گذاری و نوشتن فایل ها شود.
ضمناً اگر از فایل های باینری استفاده می کنید، می توانید از یک عبارت رمزی کوچک در ابتدای فایل خود استفاده کنید. این عبارت که می تواند به عنوان معرفه فرمت فایل شما باشد، می تواند تا حدودی امنیت فایل ها را نیز تضمین کند. علاوه بر این می توانید برای اطمینان از صحت فایل های خود (عدم دستکاری توسط دیگران)، برخی مشخصه های مهم آنها، همچون اندازه و یا ساختار داده ها را بررسی کنید. اگر چه تقریباً هیچگاه نمی توان از دستکاری فایل های هنری (تصاویر، مدل ها، صداها و...) توسط افراد کنجکاو و باهوش جلوگیری کرد، ولی بهتر است با اعمال برخی تکنیک های ساده، ضریب امنیتی فایل های خود را افزایش دهید.
البته بسته به زبانی که برای توسعه بازی بکار می برید، می توانید از روش های مختلفی برای کار با فایل ها استفاده کنید. کارایی این روش ها در مورد فایل های کوچک، تفاوت چندانی ندارد. پس بهتر است روشی را برگزینید که ضمن سادگی، بیشترین قابلیت را در اختیار شما قرار دهد. در عین حال برای اینکه از سردرگمی در هنگام ذخیره و بازیابی فایل ها در امان باشید، بهتر است توابع جداگانه ای برای کار با فایل ها (خواندن و نوشتن و تحلیل و یا رمز گذاری داده ها) داشته باشید. به این ترتیب ورودی توابع شما می تواند نام فایل مورد نظر و داده های مورد نظر ذخیره باشد.
در مورد مسیر فایل ها نیز بهتر است در هنگام برنامه نویسی، از مسیرهای نسبی استفاده کنید. یعنی تا حد امکان از آوردن نام یک درایو خاص و یا پوشه های متعدد اجتناب کنید. به این ترتیب برنامه نهایی شما، بر روی هر سیستمی قابل اجرا خواهد بود و مشکلی از نظر یافتن فایل ها وجود نخواهد داشت.
منبع: ماهنامه دانش و کامپیوتر، شماره ی 75
این بهره گیری از داده های بیشتر، در اغلب اوقات خود را به صورت افزایش حجم بازی و بعضاً عرضه آن بر روی DVD نمایان می کند، چیزی که این روزها بسیار مرسوم شده و در حال تبدیل شدن به یک عادت می باشد، به این معنی که عموم کاربران بازی ها نیز تصور می کنند با افزایش حجم بازی (تعداد CDهای بیشتر و یا عرضه بازی روی DVD)، قطعاً کیفیت بازی نیز افزایش خواهد یافت (اگر چه این مسئله در حالت کلی به هیچ وجه صحت ندارد).
با ذکر این مقدمه، در این نوشتار قصد داریم یکی از جنبه های تقریباً پنهان روند توسعه بازی، یعنی فعالیت های فایلی (بازیابی و حتی ذخیره فایل ها) را بررسی کنیم. بخاطر داشته باشید که ما قرار نیست دستورات برنامه نویسی یا الگوریتم های ویژه ای را معرفی کنیم، بلکه بیشتر قصد داریم با فرآیند کلی بازیابی و ذخیره فایل ها در بازی ها (بعنوان نرم افزارهایی بسیاربزرگ و پرحجم) آشنا شویم.
البته در مرحله اول بهتر است راه های گوناگون بکار رفته در روند بازیابی محتوای بازی ها را بررسی کنیم. این محتوا که بصورت فایل های برنامه ظاهر می شود، می تواند در برگیرنده مدل ها، تصاویر، منوها، بافت ها، انیمیشن ها، صداها و یا موسیقی ها باشد.
فیلم های بازی هم که این روزها بخش بزرگی از این محتوا را تشکیل می دهند. ضمن اینکه شاید در وهله اول، ساده ترین راهی که برای بار گذاری این فایل ها به نظر می رسد، خواندن یکباره تمامی آنها در زمان شروع بازی باشد. اما باید تاکید نمود که این روند کم کم در حال منسوخ شدن است، زیرا باعث کند شدن شروع بازی و افزایش زمان انتظار برای بازیکن می شود، و گاهی نیز می تواند با اشتغال کردن تمامی فضای حافظه، موجب بروز خطاهای حافظه ای شود.
البته یک برنامه نویس، روش خود را با توجه به نوع وسبک بازی، توانایی خود و سایر ملاحظات فنی و غیرفنی انتخاب می کند و در صورت مناسب بودن حجم محتوای فایل های بازی، این روش هنوز هم می تواند کارایی خوبی داشته باشد.
ضمناً توجه شما را به این نکته جلب می کنیم، که در اغلب مواقع، تصاویر و یا اطلاعاتی که در هنگام شروع بازی ها (که برخی مواقع صبر و حوصله کاربر را لبریز می کند)، به کاربر نشان داده می شوند، معمولاً راهی برای جلب توجه کاربر و در نتیجه داشتن فرصت برای انجام عملیات طولانی، زمانبر و خسته کننده بار گذاری فایل ها در پشت پرده می باشد. البته در برخی موارد نیز بجای تصاویر ثابت، از قطعات انیمیشنی ساده استفاده می شود. علاوه بر این می توان بجای خواندن یکباره کلیه فایل ها (که ممکن است زمان زیادی صرف کند)، این فرآیند را در چند مرحله در زمان شروع بازی انجام داد. این کاری است که احتمالاً در بسیاری از بازی ها دیده اید (یعنی مقداری از فایل ها خوانده می شوند، سپس تصویر جدیدی ظاهر شده و از شما درخواست می کند کلیدی را بزنید، سپس دوباره فایل های بیشتری خوانده می شوند. این عملیات ممکن است به اشکال مختلف ادامه یابد تا اینکه کل فایل های لازم وارد حافظه شوند). البته خواندن فیلم (انیمیشن ) ابتدای بازی، معمولاً توسط الگوریتم های پیچیده جریانی (Stream) انجام می گیرد و به همین جهت زمان زیادی برای بارگذاری و پخش آن صرف نمی شود، به این ترتیب که بجای خواندن کل فایل انیمیشن (که اغلب حجم بسیار بالایی دارد)، مقدار کمی از آن خوانده و پخش می شود، و در همین زمان قسمت بعدی فایل وارد حافظه شده و در یک بافر موقتی جای می گیرد. پس از اتمام پخش قسمت اول، قسمت دوم از بافر وارد حافظه اصلی شده و پخش می گردد ؛این روند تا پخش کل انیمیشن ادامه می یابد.
گرچه استفاده از رویکرد جریانی (یعنی خواندن بخشی از فایل و نمایش بخشی دیگر در همان زمان) برای سایر انواع فایل های بازی (همچون مدل ها و تصاویر)، کاربرد ندارد، ولی برخی APIها همچون DirectMusic امکان بهره گیری از این تکنیک را جهت تسریع عملیات بار گذاری موسیقی دارند. API قدرتمند DirectShow (که البته درDirectX 10 مجدداً از API جدا شده است) نیز امکان بهره گیری از این تکنیک را ارائه می کند و به همین جهت مورد استفاده بسیاری از بازی ها، برای پخش قطعات کلیپ و فیلم قرار می گیرد.
* اما انتقال کلیه محتویات فایل های بازی در زمان شروع، به درون حافظه (حافظه اصلی، حافظه سریع و محدود کارت گرافیکی، حافظه محلی، و یا حافظه AGP)، با توجه به رشد سریع حجم فایل ها، امروزه در بسیاری از موارد، عملی و منطقی نمی باشد. اگر سبک بازی و همچنین سیستم های نهایی مورد نظر برای اجرای بازی، نقش مهمی در تعیین تکنیک بکار رفته دارند، ولی رویکردی که در حال حاضر بسیار رواج یافته است، بار گذاری غیرپیوسته محتویات فایل های بازی می باشد، به گونه ای که در هر زمان صرفاً محتوای لازم برای نمایش هر صحنه بار گذاری شده و پس از اتمام هر صحنه، بیشتر این فایل ها از حافظه خارج می شوند تا امکان بار گذاری فایل های جدید برای سایر صحنه ها فراهم شود.
این رویکرد می تواند تضمین کننده افزایش سرعت بار گذاری و حتی اجرا باشد، زیرا در صورت مدیریت صحیح حافظه، در هر لحظه کمترین میزان ضروری از حافظه اشغال بوده و امکان تغییر مکان سریع محتوای هنری (بعنوان مثال، انتقال بافت های لازم برای رندر صحنه ها از RAM به حافظه قابل دسترسی پردازنده گرافیکی)، وجود خواهد داشت.در عین حال پیاده سازی این روش دشوار بوده و احتیاج به درک بالایی از ساختار حافظه، آشنایی با تکنیک های نوین مدیریت حافظه و بهره گیری از منابع مدیریت شده (Managed Resource)دارد. منابع مدیریت شده، گونه نسبتاً جدیدی از منابع می باشند که Direct3D نیز بخوبی از آنها پشتیبانی می کند. این منابع که می توانند شامل بافت ها، مدل ها و تصاویر مختلف باشند، قابلیت انتقال بین بخش های مختلف حافظه را دارا بوده و کاربرد مناسبی از نظر بازیابی دارند. البته استفاده از این رویکرد بازیابی فایل ها در کلیه انواع بازی ها، قابل ا ستفاده نمی باشد.
بعنوان مثال، در یک بازی ورزشی مانند فوتبال که تقریباً تمامی مدل ها، تصاویر و انیمیشن ها در یک صحنه واحد (زمین بازی ) به طور همزمان به نمایش در می آیند، نمی توان این روش را با کارآیی بالایی بکار برد. در عوض در بازی های ماجرایی و یا مرحله ای، استفاده از این روش آسانتر بوده و موجب بهبود عملکرد اجرایی برنامه خواهد شد. همچنین همواره بخاطر داشته باشید که عملیات های فایلی (یعنی خواندن و نوشتن)، بصورت بالقوه کند هستند، زیرا فعالیت دیسک سخت (که عمدتاً بصورت مکانیکی می باشد)، علی رغم تمامی پیشرفت های صورت گرفته، هنوز نسبت به فعالیت های انجام گرفته در حوزه حافظه RAM، بسیار کند محسوب می شود، در نتیجه برنامه نویسان سعی می کنند تا حد امکان از بار گذاری فایل ها در حین نمایش صحنه ها، اجتناب کنند. البته در برخی موارد، به ناچار بار گذاری تصاویر بافتی در زمان نمایش صحنه ها، ضرورت می یابد (مثلاً خواندن بافت های کوچکتر و یا بزرگتر برای استفاده در تکنیک Mipmap) که این مسئله می تواند موجب کاهش سرعت اجرای برنامه و حتی در مواردی توقف چند لحظه ای اجرا شود.
باید توجه داشته باشید که حجم فایل های موجود بر روی دیسک، ممکن است در حافظه اجرایی برنامه به چندین برابر برسد، و این مسئله ای است که می تواند باعث کاهش سرعت اجرایی و همچنین افزایش احتمال بروز خطا در روند اجرای صحیح برنامه شود. همچنین هنوز هم بهتر است برای تست روند خواندن فایل ها در بازی خود، از سیستم های نسبتاً قدیمی تر بهره ببرید، زیرا اختلاف زمان بار گذاری فایل ها در دیسک های سخت جدید و قدیم (که فن آوری هایی مانند SATA را ندارند)، ممکن است بسیار قابل توجه باشد، در این صورت احتمالاً باید روند بار گذاری را به شکل هوشمندانه ای در سیستم های مختلف مدیریت کنید تا کاربران برنامه شما بتوانند با خیال راحت برنامه را در طیف وسیعی از سیستم ها اجرا کنند.
* اما فعالیت های فایلی یک بازی، تنها به عملیات خواندن فایل ها محدود نمی شود، و تقریباً تمامی انواع بازی ها احتیاج دارند داده های خاصی را جهت ذخیره (و بازیابی بعدی) بر روی فایل ها بنویسند. این فرآیند نوشتن، می تواند به سادگی نوشتن امتیازات بازیکنان، گزینه های مختلف بازی و یا به پیچیدگی نوشتن مراحل طی شده یک بازیکن و یا ثبت صحنه های پخش شده در یک بازی ورزشی باشد. البته نکته مهم در هر صورت بدست آودن ساختار مناسب برای ذخیره داده ها می باشد، زیرا در این صورت شما می توانید صرفاً با پر کردن چند ساختار، داده های مورد نظر خود را در فایل ها بنویسید.
در هر حال یادتان باشد که تا حد امکان از انجام فعالیتهای دیسکی (بخصوص نوشتن ) در حین رندر صحنه ها خودداری کنید. در واقع اگر می خواهید مراحل طی شده و دارایی های بازیکن (تعداد جان ها «تعداد زندگی هایی که می تواند داشته باشد»، تعداد اشیاء گران قیمت جمع آوری شده، امتیازات و ...) را در طول یک بازی ماجرایی ثبت کنید، بهتر است آنها را همچون بسیاری از بازی های معروف این کار، در نقاط خاصی که اصطلاحاً Check Point نامیده می شوند، انجام دهید تا بتوانید با نمایش یک تصویر کوچک و توقف چند لحظه ای بازی، کاربر را از توجه به فعالیت دیسک باز دارید.
بخاطر داشته باشید که پس از اتمام کارتان با یک فایل، حتماً آن را ببندید تا از اتلاف حافظه و فعالیت اضافه دیسک سخت، جلوگیری شود.
ناگفته نماند، برخی از بازی ها نیز امکان ثبت تعداد نامحدودی فایل های ذخیره (Save) را به بازیکن می دهند. برای مدیریت بهتر فایل های ذخیره و سهولت در روند بازیابی (Load) آنها، می توانید از یک فایل کوچک برای ثبت کلیه فایل های ذخیره و داده های مربوط به آنها (بعنوان مثال، زمان و تاریخ ذخیره و یا اطلاعاتی در رابطه با موقعیت بازیکن در هنگام ذخیره بازی)، استفاده کنید. حتی می توانید امکان نامگذاری فایل ذخیره را نیز به بازیکن بدهید. به این ترتیب باید فایل های ذخیره را در پوشه ای جداگانه نگه داری کنید و ضمن رعایت مسائلی امنیتی، در هنگام بار گذاری فایل ها نیز نام آنها را با نام ثبت شده در فایل راهنمای ذخیره، تطبیق دهید.
* در انتها بد نیست چند نکته اساسی و مهم در کار با فایل ها را مرور کنیم. تقریباً در هر حالتی، کار با فایل های باینری، بهتر از کار با فایل های متنی می باشد. زیرا علاوه بر عدم امکان مشاهده و تغییر آنها توسط کاربران عادی، خواندن و همچنین نوشتن آنها نیز به مراتب سریعتر است (مثلاً یک عدد اعشاری در حالت متنی می تواند به حدود 10 تا 14بایت فضا احتیاج داشته باشد، در حالیکه همین عدد در حالت باینری، تنها در 4 بایت قابل ذخیره است).
در واقع هر چه تعداد عملیات های فایلی کمتر باشد، سرعت برنامه بیشتر خواهد بود، در نتیجه تا حد امکان دستورات خواندن و نوشتن فایل را کاهش دهید (مثلاً بهتر است بجای ده بار نوشتن مجموعه اعداد اعشاری، آنها را در یک ساختار ذخیره کرده و ساختار مورد نظر را با یک دستور بنویسید. به این ترتیب خواندن فایل نیز با استفاده از همین ساختار، به مراتب سریعتر انجام خواهد شد). همچنین سعی کنید از نامگذاری فایل ها، با اسامی خیلی طولانی پرهیز کنید، زیرا این کار می تواند موجب بروز خطا در فرآیند بار گذاری و نوشتن فایل ها شود.
ضمناً اگر از فایل های باینری استفاده می کنید، می توانید از یک عبارت رمزی کوچک در ابتدای فایل خود استفاده کنید. این عبارت که می تواند به عنوان معرفه فرمت فایل شما باشد، می تواند تا حدودی امنیت فایل ها را نیز تضمین کند. علاوه بر این می توانید برای اطمینان از صحت فایل های خود (عدم دستکاری توسط دیگران)، برخی مشخصه های مهم آنها، همچون اندازه و یا ساختار داده ها را بررسی کنید. اگر چه تقریباً هیچگاه نمی توان از دستکاری فایل های هنری (تصاویر، مدل ها، صداها و...) توسط افراد کنجکاو و باهوش جلوگیری کرد، ولی بهتر است با اعمال برخی تکنیک های ساده، ضریب امنیتی فایل های خود را افزایش دهید.
البته بسته به زبانی که برای توسعه بازی بکار می برید، می توانید از روش های مختلفی برای کار با فایل ها استفاده کنید. کارایی این روش ها در مورد فایل های کوچک، تفاوت چندانی ندارد. پس بهتر است روشی را برگزینید که ضمن سادگی، بیشترین قابلیت را در اختیار شما قرار دهد. در عین حال برای اینکه از سردرگمی در هنگام ذخیره و بازیابی فایل ها در امان باشید، بهتر است توابع جداگانه ای برای کار با فایل ها (خواندن و نوشتن و تحلیل و یا رمز گذاری داده ها) داشته باشید. به این ترتیب ورودی توابع شما می تواند نام فایل مورد نظر و داده های مورد نظر ذخیره باشد.
در مورد مسیر فایل ها نیز بهتر است در هنگام برنامه نویسی، از مسیرهای نسبی استفاده کنید. یعنی تا حد امکان از آوردن نام یک درایو خاص و یا پوشه های متعدد اجتناب کنید. به این ترتیب برنامه نهایی شما، بر روی هر سیستمی قابل اجرا خواهد بود و مشکلی از نظر یافتن فایل ها وجود نخواهد داشت.
منبع: ماهنامه دانش و کامپیوتر، شماره ی 75
