گردش‌کار دارایی بازی با AI

پیش از تولید هنر، قرارداد دارایی بنویسید

نقش دارایی در بازی را تعریف کنید: sprite بازیکن، مانع، کاشی پس‌زمینه، دکمه، نشانه صوتی یا ماده تبلیغاتی. اندازه، شفافیت، چیدمان فریم، زاویه دید، محدودیت‌های پالت و مقیاس بررسی را مشخص کنید. این موارد را ورودی تولید بدانید، نه اینکه امیدوار باشید تصویر زیبا بعداً مناسب شود.

برای sprite sheet تعداد فریم، اندازه سلول، مبدأ و حالت‌های مورد انتظار انیمیشن را مشخص کنید. برای دارایی UI متن پیرامون و وضعیت تعامل را شناسایی کنید. تا پایدار شدن قرارداد از placeholder متعلق به خود استفاده کنید تا تکرار هنری پنهان نکند که gameplay کار می‌کند یا نه.

منبعی با مبنای مجوز قابل‌بررسی انتخاب کنید

منابع ممکن شامل کار سفارشی اصیل، دارایی‌های خودنوشته، بسته دارای مجوز یا محتوای تولیدشده تحت شرایط سرویس بررسی‌شده است. آن‌ها را بر اساس مجوز، قابلیت ویرایش، سازگاری و تلاش بازبینی مقایسه کنید، نه بر اساس ادعای اثبات‌نشده که یک منبع همیشه ارزان‌تر است.

پیوند منبع اصلی و مجوز یا توافق مربوط را همراه رکورد دارایی نگه دارید. الزامات attribution و بازتوزیع را ثبت کنید. محتوای تولیدشده نیز به بررسی ورودی و خروجی نیاز دارد؛ دسترسی مدل، مجوز شخصیت‌های کپی‌شده، علامت‌ها یا مواد محافظت‌شده دیگر را ثابت نمی‌کند. حقوق مبهم را پیش از توزیع پیگیری کنید، نه اینکه عدم‌قطعیت را به وضعیت تأییدشده تبدیل کنید.

کدنویسی و تولید تصویر را قابل‌انتساب نگه دارید

Astra می‌تواند موضوع آزمایش کدنویسی باشد، در حالی که ابزار تصویری جداگانه هنر را تولید می‌کند. این نقش‌ها را جداگانه ثبت کنید. دستور متنی برای ساخت sprite ثابت نمی‌کند کدام سرویس پیکسل‌ها را تولید کرده و جلسه موفق کدنویسی صورت‌حساب سرویس تصویر را فراهم نمی‌کند.

برای هر خروجی تولیدشده هویت واقعی ابزار تصویر، رکورد درخواست در صورت وجود، تنظیمات تولید، خروجی انتخاب‌شده و ویرایش‌های دستی را حفظ کنید. تلاش‌های ناموفق یا کنارگذاشته‌شده را در دفتر مصرف بگذارید. کار تصویر را از کدنویسی متن جدا پیگیری کنید، حتی اگر یک عامل هر دو را هماهنگ کند، تا پرونده نشان دهد هزینه و تلاش انسانی واقعاً کجا صرف شده است.

از manifest با ناشناخته‌های صادقانه استفاده کنید

برای pipeline دارایی از رکورد نمونه زیر استفاده کنید و فیلدهای ناشناخته را تا زمان بررسی null نگه دارید. تأیید به منبع واقعی، تصمیم مجوز، هویت فایل و بررسی فنی نیاز دارد. هنگام جایگزین کردن خروجی، شناسه دارایی را ثابت نگه دارید تا فایل جدید زمینه را به ارث ببرد، نه تأیید ناحق را.

ماده خام و خروجی نهایی import‌شده را با همان شناسه دارایی پیوند دهید. وقتی انسانی پس‌زمینه را حذف، فریم انیمیشن را تعمیر یا کنتراست را تغییر می‌دهد، این تبدیل را ثبت کنید. این کار جایگزینی بعدی، بررسی attribution و اشکال‌زدایی را بدون اتکا به حافظه جلسه chat ممکن می‌کند.

{
  "asset_id": "player_idle",
  "source_url": null,
  "permission_record": null,
  "creator_or_tool": null,
  "source_hash": null,
  "final_file_hash": null,
  "transformations": [],
  "image_cost_record": null,
  "review_status": "pending",
  "import_result": null
}

Import موتور را بررسی کنید، نه فقط فایل منبع را

مستندات import تصویر Godot گزینه‌های فشرده‌سازی و mipmap را که بر textureهای import‌شده اثر می‌گذارند توضیح می‌دهد. تنظیمات را بر اساس شرایط واقعی نمایش دارایی انتخاب کنید؛ pixel art، پس‌زمینه مقیاس‌شده و textureهای 3D یک preset عمومی ندارند. تنظیمات خروجی پذیرفته‌شده را نگه دارید.

لبه‌های شفاف، پس‌زمینه ناخواسته، فاصله فریم و مقیاس دیداری داخل بازی را بررسی کنید. نمایش collision را با شیء قابل‌دیدن مقایسه کنید. PNG فنی معتبر ممکن است به‌دلیل جابه‌جایی موقعیت ظاهری شخصیت در فریم‌ها یا ناپدید شدن sprite روی سطح مرحله غیرقابل‌استفاده باشد. پیش از انتشار دارایی در صحنه‌های بسیار، این مشکلات را رد کنید.

انیمیشن، صدا و UI را در زمینه بررسی کنید

عمل مرتبط را چندبار اجرا و انتقال میان حالت‌های انیمیشن را بررسی کنید. ببینید زمان‌بندی تصویر با collision و بازخورد هماهنگ است یا نه. contact sheet فریم‌به‌فریم می‌تواند به بررسی کمک کند، اما جای مشاهده انیمیشن در حال اجرا و ورودی بازیکنِ فعال‌کننده آن را نمی‌گیرد.

برای صدا، سازگاری سطح، loop، زمان‌بندی و سوابق مجوز را مستقل از بررسی تصویر بررسی کنید. برای هنر UI، focus، حالت غیرفعال و کنتراست متن را در وضوح موردنظر بسنجید. شکست‌ها را بر اساس دارایی و رفتار ثبت کنید تا عامل بازخورد عملی دریافت کند، نه درخواست کلی برای زیباتر کردن بازی.

artifact خروجی و فهرست افشا را بررسی کنید

حضور دارایی‌های پذیرفته‌شده در build خروجی و رفتار بررسی‌شده آن‌ها را تأیید کنید. هنگام ادعای پیاده‌سازی، تصویر یا ضبطی از artifact واقعی نگه دارید. تصویر مفهومی یا mockup تولیدشده را جایگزین مدرک gameplay نکنید.

فهرست انتشار را طوری نگه دارید که هنر، صدا، روایت، بومی‌سازی و خروجی زمان اجرا را جدا کند. برای تعیین موارد لازم درباره بازی واقعی، راهنمای آماده‌سازی Steam و Content Survey جاری را استفاده کنید. رکورد داخلی دارایی به بررسی کمک می‌کند، اما به‌تنهایی تأیید پلتفرم یا حل پرسش حقوقی مبهم را ثابت نمی‌کند.

برای دارایی پذیرفته‌شده، از جمله بازکاری، بودجه بگذارید

تولید دارایی را با نتیجه پذیرفته‌شده داخل بازی بسنجید، نه فقط تعداد فایل‌های تولیدشده. تولیدهای ردشده، پاک‌سازی دستی، اصلاح import و بررسی دوباره build هدف را ثبت کنید. به‌جای قراردادن قیمت در راهنما، از دسته‌ها و تاریخ‌های واقعی صورت‌حساب ارائه‌دهنده استفاده کنید.

اگر تولیدهای تکراری همان نیاز فنی را برآورده نمی‌کنند، قرارداد دارایی را بازبینی یا هنگام حل gameplay از placeholder اصلی استفاده کنید. prompt بیشتر، چیدمان فریم تعریف‌نشده را جبران نمی‌کند. این رویه و فیلدهای manifest نمونه‌اند؛ پیش از پذیرش دارایی یا برآورد batch بعدی، فایل‌ها و شرایط واقعی را ارزیابی کنید.

پرسش‌های پرتکرار