از ایده بازی تا prototype playable

ایده خوب از کجا شروع می‌شود؟

بسیاری فکر می‌کنند بازی‌سازی با «ایده ناب» شروع می‌شود؛ در عمل، ایده‌های خوب اغلب از محدودیت، تمرکز و تکرار emerge می‌شوند. یک ایده اولیه می‌تواند ساده باشد: «بازیکن در محیط محدود از دشمن فرار کند» یا «پازل با مکانیک چرخش». مهم نیست ایده در ابتدا کامل باشد؛ مهم است قابل prototype باشد.

در Nova Lab از دانشجویان می‌خواهیم ایده را در یک جمله بنویسند: بازیکن چه می‌کند، در چه محیطی و با چه هدفی؟ این فرمول ساده (اکشن + زمینه + هدف) جلوی پروژه‌های بیش از حد پیچیده را می‌گیرد. بازی‌های موفق مستقل اغلب یک مکانیک اصلی قوی دارند، نه ده مکانیک متوسط.

ایده را با چند سوال محک بزنید: آیا در یک هفته prototype ساده‌اش قابل ساخت است؟ آیا می‌توانید بدون asset گرافیکی پیچیده آن را تست کنید؟ آیا خودتان حاضرید آن را چند بار بازی کنید؟ اگر پاسخ منفی است، scope را کوچک کنید — این یک مهارت حرفه‌ای است، نه شکست.

brainstorm گروهی در کلاس Nova Lab اغلب ایده‌های اولیه را ساده‌تر و قابل اجرا می‌کند. وقتی ایده را با دیگران به اشتراک می‌گذارید، زوایای ضعیف زودتر دیده می‌شوند. نگران دزدیده شدن ایده در مرحله آموزشی نباشید — ارزش در execution و iteration است، نه در ایده خام.

ژانرهای شناخته‌شده (platformer، top-down shooter، puzzle) برای اولین prototype مزیت دارند: بازیکن و شما هر دو انتظارات مشخص دارید و تمرکز روی یک twist کوچک می‌ماند. نوآوری کامل در prototype اول معمولاً overkill است.

سند طراحی بازی (GDD) در مقیاس کوچک

GDD سند رسمی طراحی بازی است؛ برای prototype اولیه نیازی به سند صدصفحه‌ای نیست. یک GDD کوچک — معمولاً یک تا سه صفحه — شامل مفهوم اصلی، مکانیک‌های کلیدی، کنترل‌ها، قوانین برد و باخت، و لیست assetهای ضروری کافی است. هدف GDD در این مرحله هم‌راستایی ذهن شما و تیم (یا مربی) است، نه مستندسازی برای ناشر.

بخش‌های پیشنهادی: خلاصه یک‌خطی، توضیح گیم‌پلی حلقه اصلی (core loop)، فهرست featureهای «باید داشته باشد» در v0.1 و featureهای «بعداً». جدا کردن این دو لیست از scope creep جلوگیری می‌کند — مشکلی که prototypeهای نیمه‌کاره را متوقف می‌کند.

نقشه ساده level روی کاغذ یا در ابزار طراحی — حتی sketch — قبل از greybox کمک می‌کند فضای بازی را تصور کنید و از rebuild بی‌هدف صحنه در Unity جلوگیری کند.

در دوره unity-game-dev، دانشجویان GDD کوچک خود را قبل از شروع کدنویسی تحویل می‌دهند. این گام کوتاه اما حیاتی است: وقتی در وسط پروژه گیر کردید، به GDD برمی‌گردید و می‌بینید آیا مشکل از کد است یا از ابهام در طراحی. بسیاری از bugهای «احساسی» در بازی‌سازی ریشه در طراحی مبهم دارند.

یک بخش مفید در GDD کوچک، «ریسک‌ها و ابهام‌ها» است: چه چیزی هنوز نمی‌دانید و با prototype باید بسنجید؟ مثلاً «آیا سرعت دشمن جذاب است یا خسته‌کننده؟» — این سوال مستقیماً به playtest و تنظیم اعداد در Unity وصل می‌شود.

تعریف scope برای نسخه 0.1

Prototype playable نسخه 0.1 بازی شماست: نه polished، نه کامل، اما قابل بازی از شروع تا پایان (یا حلقه اصلی). برای یک بازی اکشن ساده، scope ممکن است شامل حرکت بازیکن، یک نوع دشمن، یک سطح، امتیاز و شرط باخت باشد. هر چیزی خارج از این — منوی زیبا، چند سطح، داستان — برای v0.2 است.

قانون عملی Nova Lab: «اگر feature برای تست گیم‌پلی اصلی لازم نیست، در v0.1 نیست.» این قانون سخت به نظر می‌رسد، اما سرعت ساخت و یادگیری را چند برابر می‌کند. شما زودتر feedback واقعی می‌گیرید و زودتر می‌فهمید ایده جالب است یا باید pivot کنید.

MoSCoW (Must / Should / Could / Won't) روش سادهی برای اولویت‌بندی است: فقط Mustها در v0.1. Shouldها برای v0.2 و Couldها شاید هرگز — این جدول را کنار GDD نگه دارید.

scope را روی کاغذ یا ابزار مدیریت پروژه بنویسید و کنار هر آیتم تخمین زمان بزنید. اگر مجموع بیش از دو هفته برای یک prototype آموزشی است، دوباره کوچک کنید. در صنعت، حتی تیم‌های حرفه‌ای prototypeهای یک تا دو هفته‌ای می‌سازند قبل از سرمایه‌گذاری بزرگ.

تعریف «تعریف done» برای هر feature کمک می‌کند: «حرکت بازیکن done است وقتی با WASD و collision درست حرکت کند» — نه وقتی انیمیشن walk نهایی اضافه شود. این تفکیک بین functional و polished در scope v0.1 حیاتی است.

ساخت سریع در Unity: greybox و placeholder

در مرحله prototype، گرافیک نهایی دشمن است. از Primitiveهای Unity (Cube، Sphere، Capsule) برای زمین، بازیکن و دشمن استفاده کنید. رنگ‌های ساده در Material کافی است. Cinemachine یا دوربین ساده برای دنبال کردن بازیکن. Input System یا ورودی legacy برای حرکت. هدف: در عرض چند روز یک صحنه playable داشته باشید.

اسکریپت‌ها در این مرحله باید کوتاه و مستقیم باشند: PlayerMovement، EnemyPatrol، GameManager برای score و game over. از الگوهای پیچیده و architecture سنگین پرهیز کنید تا وقتی گیم‌پلی را عوض می‌کنید، refactor ساعت‌ها طول نکشد. کد تمیز مهم است، اما کد زنده که تست می‌شود از کد زیبای بدون بازی ارزش بیشتری دارد.

Nova Lab در تمرین‌های prototype تأکید بر «vertical slice کوچک» دارد: یک مسیر کامل از spawn بازیکن تا تعامل با یک مکانیک و نتیجه (امتیاز یا باخت). این slice پایه‌ای برای گسترش است. بسیاری از بازی‌های indie موفق ابتدا چنین slice کوچکی ساخته‌اند و سپس حول آن expand کرده‌اند.

Prefab در Unity برای بازیکن و دشمن از همان prototype مفید است: یک بار تنظیم کنید و در چند صحنه استفاده کنید. حتی در greybox، habit ساخت Prefab شما را برای فاز production آماده می‌کند و duplicate و inconsistency را کم می‌کند.

Scene management ساده — یک scene gameplay و یک scene game over — برای v0.1 کافی است. از multi-scene پیچیده در prototype اول پرهیز کنید؛ بعداً با SceneManager.LoadScene گسترش می‌دهید.

حلقه اصلی گیم‌پلی (Core Loop)

Core loop مجموعه اقداماتی است که بازیکن بارها تکرار می‌کند: حرکت → مبارزه → جمع امتیاز → ریسک بیشتر → دوباره. اگر این حلقه در prototype جذاب نیست، بازی کامل هم احتمالاً جذاب نمی‌شود. بنابراین زمان اصلی prototype را روی polish حلقه اصلی بگذارید، نه روی جزئیات جانبی.

برای تست core loop، از خودتان بپرسید: آیا بعد از پنج دقیقه بازی هنوز می‌خواهم ادامه دهم؟ اگر نه، چه چیزی کم است — سرعت، feedback، challenge، variety؟ تغییرات کوچک در اعداد (سرعت دشمن، میزان damage، spawn rate) اغلب تأثیر بزرگ دارند. این تنظیمات را در Inspector یا ScriptableObject قابل تغییر نگه دارید.

در کلاس Nova Lab، sessionهای playtest کوچک بین دانشجویان برگزار می‌شود. دیدن کسی که بدون توضیح شما بازی می‌کند، اطلاعاتی است که هیچ تحلیل شخصی نمی‌دهد. بازیکن ممکن است جایی گیر کند که شما فکر می‌کردید واضح است — این بازخورد gold است.

juice و feedback — صدای hit، flash کوتاه، particle ساده — حتی در prototype می‌تواند core loop را قابل تشخیص جذاب‌تر کند. هزینه زمانی کم است و در playtest تفاوت ایجاد می‌کند؛ Nova Lab معمولاً یک session روی «feedback بازیکن» در همان هفته greybox دارد.

تست، بازخورد و تکرار

Prototype بدون playtest فقط demo است. playtest یعنی کسی بازی کند و شما بدون دفاع از طراحی، رفتار او را ببینید و یادداشت بردارید. سوالات خوب بعد از تست: «کجا گیج شدی؟» «چه موقع حوصله‌ات سر رفت؟» «آیا می‌خواستی دوباره بازی کنی؟»

بازخورد را به لیست actionable تبدیل کنید: «دشمن خیلی سریع است» → کاهش speed؛ «نمی‌دانستم چطور بزنم» → افزودن hint یا animation. هر iteration کوچک و measurable باشد. اگر بعد از سه iteration core loop بهتر نشد، شاید وقت pivot یا ساده‌سازی بیشتر است — این هم بخش طبیعی فرآیند است.

در Nova Lab، iterationها بخشی از ارزیابی پروژه هستند. ما به دنبال بازی polished نهایی در هفته چهارم نیستیم؛ به دنبال نشان دادن فرآیند فکر، پاسخ به feedback و بهبود measurable هستیم. این مهارت در استودیوها به «iteration velocity» معروف است و بسیار ارزشمند است.

لاگ تغییرات کوتاه (changelog) برای هر iteration بنویسید: «v0.1.2 — سرعت دشمن ۲۰٪ کم شد؛ hint تیر اول اضافه شد.» این سند برای خودتان و برای portfolio نشان می‌دهد شما designer فکر می‌کنید، نه فقط coder.

از prototype به قدم بعدی

وقتی prototype playable دارید — شروع، gameplay، پایان یا حلقه — شما یک milestone واقعی دارید. این milestone را در portfolio نشان دهید: ویدیو کوتاه gameplay، چند screenshot و توضیح design decisions. برای استخدام junior یا پروژه freelance، چنین نمونه‌کارها اغلب از رزومه خالی ارزش بیشتری دارند.

قدم‌های بعدی بسته به نتیجه prototype: اگر core loop قوی است، featureهای v0.2 (سطح دوم، UI بهتر، صدا) را اضافه کنید. اگر ضعیف است، قبل از expand کردن، loop را fix کنید. اگر ایده جواب نداد، از مهارت‌های Unity که یاد گرفتید برای prototype جدید استفاده کنید — زمان شما در engine و workflow تلف نشده.

مسیر از ایده تا prototype playable همان چیزی است که دوره unity-game-dev در Nova Lab شبیه‌سازی می‌کند: ایده → GDD کوچک → scope → greybox → core loop → playtest → iterate. اگر این چرخه را یک بار کامل تجربه کنید، برای پروژه‌های بعدی — چه در Unity چه در تیم — آماده‌تر از ۹۰ درصد کسانی که فقط ویدیو تماشا کرده‌اند خواهید بود.

game jamها (حتی آنلاین) فرصت خوبی برای تکرار این چرخه در ۴۸ یا ۷۲ ساعت هستند. Nova Lab اغلب دانشجویان را به jamهای مناسب مبتدی معرفی می‌کند؛ فشار زمانی آموزش می‌دهد scope را کوچک نگه دارید و روی playable اولویت بگذارید.