این پژوهش را با این انتظار شروع کردم که فقط چند آزمایش جالب دربارهٔ مبارزه در مرورگر پیدا کنم. اما در عوض با اکوسیستمی بسیار گسترده‌تر روبه‌رو شدم: نمونه‌های واقعی اکشن سوم‌شخص با قفل روی هدف، درخت‌های کمبوی شاخه‌ای، پریِ بی‌نقص، مصونیت هنگام جاخالی، سیستم‌های posture، حملات هوایی، تلگراف حملهٔ باس‌ها، motion warping، hit-stop، برخورد فیزیکی سلاح‌ها، پشتیبانی از گیم‌پد، کنترل لمسی و شبیه‌سازی قطعی.
این همان نتیجهٔ مهم است. دیگر با بازی‌های کوچکی طرف نیستیم که صرفاً اتفاقی داخل یک صفحهٔ وب رندر می‌شوند. بعضی از این پروژه‌ها همان مسائل مهندسی بازی‌های اکشن متعارف را حل می‌کنند، با این تفاوت که به‌صورت یک URL توزیع می‌شوند و می‌توان بلافاصله آن‌ها را بازی کرد.
برای من به‌عنوان یک توسعه‌دهندهٔ وب، همین بخش جذاب است. مدل ذهنی قدیمی بازی‌ها حول نصب‌کننده‌ها، دانلودهای بزرگ، ابزارهای به‌روزرسانی، لانچرها و فاصلهٔ زمانی بین پیدا کردن یک بازی و واقعاً دست زدن به آن شکل گرفته بود. مرورگر این مسیر را به‌شدت کوتاه می‌کند: یک لینک را باز کن، دارایی‌ها را بارگذاری کن و شروع به بازی کن.
این پژوهش روی پروژه‌هایی متمرکز بود که هم نسخهٔ قابل‌بازی در مرورگر داشتند و هم سورس عمومی. خروجی‌های Unity WebGL را عمداً کنار گذاشتم، چون می‌خواستم بازی‌هایی را بررسی کنم که حول فناوری‌های وب ساخته شده‌اند، نه بازی‌هایی که صرفاً برای وب خروجی گرفته شده‌اند.
قوی‌ترین پروژه‌هایی که پیدا کردم
مفیدترین یافته‌ها همگی به یک دلیل قوی نبودند. بعضی عمیق‌ترین سیستم‌های کمبو را داشتند. بعضی دیگر معماری سوم‌شخص بهتر، شبیه‌سازی مبارزهٔ تمیزتر یا ضربه‌های فیزیکی قانع‌کننده‌تری ارائه می‌کردند.
| پروژه | بهترین بخش | چه چیزی را بررسی کنیم | دمو | سورس |
|---|---|---|---|---|
| Long Wind | مبارزهٔ مدرن سوم‌شخص | قفل روی هدف، پری، posture، اجرای نهایی، واکنش به ضربه | اجرای دمو | GitHub |
| Voxel Musou | معماری کمبو | حرکت‌های شاخه‌ای، حملات هوایی، کیت شخصیت‌ها، جمعیت دشمنان | اجرای دمو | GitHub |
| Rotten Souls | پایهٔ سوم‌شخص | قفل روی هدف، جاخالی، مبارزه با باس، ساختار انیمیشن و دوربین | اجرای دمو | GitHub |
| Samurai Third-Person Template | Motion warping | جای‌گیری حمله، هدف‌گیری، راهبرد root motion | اجرای دمو | GitHub |
| Stick & Steel | مبارزهٔ تن‌به‌تن مبتنی بر فیزیک | تماس سلاح، جهت گارد، اعتبارسنجی ضربه، زمین‌زدن | اجرای دمو | GitHub |
| Jelly Colosseum | چرخهٔ فشردهٔ مبارزهٔ نزدیک | حملات سبک/سنگین، پری، استقامت، شکستن گارد، هویت سلاح | اجرای دمو | GitHub |
| Hollowmere | معماری مبارزه | شبیه‌سازی قطعی، حل‌وفصل متمرکز دفاع، تست | اجرای دمو | GitHub |
| Fabled Revolutions | حس بازی | hit-stop، لرزش دوربین، trailها، ذرات، knockback، بازخورد ضربه | اجرای دمو | GitHub |
چرا نتایج غافلگیرم کردند
بخش غافلگیرکننده فقط این نبود که گرافیک خوب به نظر می‌رسید. رندر کردن یک صحنهٔ پرداخت‌شده فقط یکی از بخش‌های توسعهٔ بازی است. پروژه‌هایی که برجسته بودند، سیستم‌هایی را پیاده کرده بودند که نمی‌شود به‌سادگی به‌طور قانع‌کننده جعلشان کرد: بافر ورودی، گذار حالت‌های مبارزه، انتخاب هدف، حرکت حمله، زمان‌بندی انیمیشن، تشخیص ضربه، واکنش دشمن، پنجره‌های دفاعی، رفتار دوربین و بازخورد برخورد.
این یک تمایز مفید ایجاد می‌کند:
- زمان‌بندی انیمیشن، زمان‌بندی مبارزه نیست؛
- نرخ فریم رندر، نرخ شبیه‌سازی نیست؛
- برخورد به‌طور خودکار به معنی ضربهٔ معتبر نیست؛
- انیمیشن لزوماً مرجع نهایی حرکت نیست؛
- تماس بصری همان حس ادراک‌شدهٔ ضربه نیست.
این تفاوت‌ها بارها در قوی‌ترین پروژه‌ها دیده شدند و از لوگوی رندرکننده در README مهم‌ترند.
Voxel Musou: مبارزه در مرورگر می‌تواند دستور زبان واقعی برای حرکت‌ها داشته باشد
Voxel Musou یکی از روشن‌ترین نمونه‌ها بود که نشان می‌دهد مبارزه در مرورگر دیگر مجبور نیست به یک انیمیشن حمله روی یک دکمه محدود شود. سورس آن در mike007jd/voxel-musou در دسترس است.
این پروژه به‌جای یک کمبوی کاملاً خطی، از زنجیره‌های بلند حملات عادی و شاخه‌های حملهٔ شارژی استفاده می‌کند. از نظر معماری مهم است، چون سیستم را می‌توان این‌طور مدل کرد:
current move + buffered input + combat state -> next moveاین پایه برای یک بازی اکشنِ شخصیت‌محور بسیار بهتر از مجموعه‌ای رو‌به‌رشد از شرط‌های استثنایی است. همچنین حملات هوایی، توالی‌های ویژه، چندین کیت شخصیت، رفتار باس، hit-stop و مبارزه با گروه‌های بزرگ دشمن را نشان می‌دهد.
درس مهندسی گسترده‌تر این است که حرکت‌ها باید به داده تبدیل شوند و گذارها باید صریح باشند. وقتی این اتفاق بیفتد، اضافه کردن یک شخصیت دیگر دیگر مستلزم بازنویسی کامل کنترلر مبارزه نیست.
Long Wind: نزدیک‌ترین نمونه به یک بازی اکشن مدرن مرورگری
Long Wind یکی از قوی‌ترین مراجع یکپارچه بود، چون حرکت سوم‌شخص را با حملات سبک و سنگین، قفل روی هدف، گارد، پری بی‌نقص، مصونیت هنگام جاخالی، فشار posture، اجرای نهایی، واکنش‌های پرتاب و زمین‌خوردن، پرتابه‌ها، باس‌ها و چندین گونهٔ دشمن ترکیب می‌کند. سورس در jbang2004/long-wind در دسترس است.
ارزش آن به این نیست که تک‌تک قابلیت‌ها بی‌سابقه‌اند؛ ارزشش این است که همهٔ آن‌ها در یک نمونهٔ اکشن بومی مرورگر کنار هم حضور دارند. به همین دلیل مرجع خوبی برای دنبال کردن کل مسیر از ورودی تا انتخاب هدف، حالت حمله، انیمیشن، تماس، واکنش، hit-stop و بازخورد دوربین است.
Motion warping مشکلی را حل می‌کند که دموهای وب اغلب نادیده می‌گیرند
Samurai Third-Person Template ThreeJS به‌ویژه جالب است، چون یکی از مسائل کلاسیک مبارزهٔ نزدیک سوم‌شخص را هدف می‌گیرد. سورس آن در achrefelouafi/SamuraiThirdPersonTemplateThreeJS در دسترس است.
یک انیمیشن حملهٔ ازپیش‌طراحی‌شده فرض می‌کند هدف در لحظه‌ای که ضربه به فریم تماس می‌رسد، در فاصلهٔ مشخصی قرار دارد. در یک بازی واقعی، هدف تقریباً هیچ‌وقت دقیقاً در جای ایده‌آل نیست. اگر شخصیت فقط انیمیشن را در همان نقطه اجرا کند، ممکن است شمشیر از نظر بصری خطا برود، در حالی که بازی همچنان آسیب را اعمال می‌کند. اگر شخصیت ناگهان به موقعیت درست جابه‌جا شود، حمله مصنوعی به نظر می‌رسد.
Motion warping پاسخ بهتری می‌دهد: چرخش و جابه‌جایی را هنگام حمله طوری تنظیم کن که شخصیت در لحظهٔ درست به نقطهٔ تماس مورد انتظار برسد.
تمایز مهم این است:
animation intent != movement authorityیک شخصیت می‌تواند نیت بصری انیمیشن ازپیش‌طراحی‌شده را حفظ کند، در حالی که کنترلر گیم‌پلی همچنان مرجع نهایی محل حرکت واقعی شخصیت باقی می‌ماند.
تشخیص برخورد و اعتبارسنجی ضربه دو مسئلهٔ متفاوت‌اند
Stick & Steel مدل مبارزهٔ بسیار متفاوتی را بررسی می‌کند. سورس آن در Rabneba/stick-steel در دسترس است.
این پروژه به‌جای اینکه شمشیر را عمدتاً یک انیمیشن با حجم آسیب در نظر بگیرد، به سلاح‌ها حضور فیزیکی می‌دهد. سرعت تماس، جهت سلاح، ناحیهٔ بدن، گاردها، برخورد سلاح‌ها، زمین‌زدن و خلع سلاح همگی مهم‌اند.
قابل‌انتقال‌ترین درس این نیست که هر بازی اکشن باید از سلاح‌های کاملاً فیزیکی استفاده کند. نکته این است:
یک برخورد به تو می‌گوید دو چیز با هم تماس داشته‌اند. اما نمی‌گوید آیا یک ضربهٔ معنادار رخ داده است یا نه.
یک سیستم مبارزهٔ قانع‌کننده اغلب به لایهٔ دومی نیاز دارد که تصمیم بگیرد آیا تماس سرعت کافی، جهت درست، ناحیهٔ درست سلاح، زمان‌بندی درست و وضعیت معتبر هدف را داشته تا به‌عنوان آسیب حساب شود.
حل‌وفصل متمرکز مبارزه، فهم دفاع پیچیده را آسان‌تر می‌کند
Hollowmere، با سورس در euuuuuuan/hollowmere-public، کمتر به‌خاطر جلوهٔ بصری و بیشتر به‌خاطر معماری نرم‌افزار برجسته بود.
شبیه‌سازی مبارزه در آن از رندر جداست و حل‌وفصل دفاع به‌صورت متمرکز انجام می‌شود. این از یک الگوی شکست رایج در بازی‌های اکشن جلوگیری می‌کند؛ جایی که سیستم جاخالی، سیستم پری، سیستم واکنش به ضربه و لایهٔ انیمیشن می‌توانند مستقل از هم دربارهٔ اصابت همان حمله اختلاف داشته باشند.
مدل ذهنی تمیزتر این است:
incoming attack -> evade | parry | hitرندرکننده باید نتیجه را نمایش دهد، نه اینکه نسخهٔ دومی از حقیقت مبارزه اختراع کند.
هرچه مبارزه بزرگ‌تر و پیچیده‌تر شود، این تمایز مهم‌تر می‌شود. شبیه‌سازی قطعی و گذارهای صریح حالت‌ها قابلیت‌های پرزرق‌وبرقی نیستند، اما تست، دیباگ و گسترش مبارزهٔ پیچیده را آسان‌تر می‌کنند.
حس بازی یک سیستم مهندسی است، نه تزئین
Fabled Revolutions، با سورس در ericrius1/FabledRevolutions، دقیقاً به این دلیل مفید است که افکت‌هایی را جدا می‌کند که باعث می‌شوند ضربه‌ها وزن و قدرت داشته باشند.
یک سیستم مبارزه که از نظر منطقی درست است، هنوز هم می‌تواند ضعیف حس شود. برخورد می‌تواند دقیق باشد، آسیب روی فریم درست اعمال شود و بااین‌حال نتیجه شبیه عبور دو مدل از داخل هم به نظر برسد.
حس ضربه اغلب از روی هم قرار گرفتن چند افکت کوتاه‌عمر می‌آید:
- hit-stop؛
- لرزش یا ضربهٔ دوربین؛
- trail سلاح؛
- ذرات برخورد؛
- فلش آسیب؛
- knockback؛
- واکنش انیمیشن؛
- صدای دقیقاً زمان‌بندی‌شده.
این یک تمایز مفید دیگر را پیشنهاد می‌کند: درستی مبارزه همان حس مبارزه نیست. یک بازی مرورگری به هر دو نیاز دارد.
رندرکننده عامل اصلی پیش‌بینی کیفیت مبارزه نبود
یکی از الگوهای جالب‌تر پژوهش این بود که بهترین مبارزه لزوماً به این وابسته نبود که پروژه از جدیدترین API رندر استفاده کند.
Three.js بارها دیده شد. بعضی پروژه‌ها از فناوری‌های رندر مرتبط با WebGPU استفاده می‌کردند و بعضی دیگر از پشته‌های متعارف مبتنی بر WebGL. موتورهای فیزیک، TypeScript، JavaScript، Vite، WebAssembly و روش‌های مختلف رندر در سراسر پژوهش دیده شدند.
اما مبارزهٔ پیشرفته به‌شکل باثبات‌تری به معماری وابسته بود: شبیه‌سازی با گام ثابت، حالت‌های صریح، هدف‌گیری قابل‌اعتماد، مالکیت منطقی انیمیشن، حرکت‌های داده‌محور، حل‌وفصل متمرکز آسیب و بازخورد خوب ضربه.
این برای توسعه‌دهندگان وب امیدوارکننده است. لازم نیست صبر کنید تا همهٔ کاربران جدیدترین پشتهٔ گرافیکی را داشته باشند تا بتوانید طراحی مبارزهٔ جدی را آزمایش کنید.
چرا توزیع از طریق مرورگر معادله را تغییر می‌دهد
مرورگر مزیتی دارد که ارتباط چندانی با گرافیک ندارد: اصطکاک توزیع بسیار پایین.
بازی‌های سنتی معمولاً چندین مرحله بین کشف بازی و تعامل واقعی قرار می‌دهند: صفحهٔ فروشگاه را پیدا کن، یک بستهٔ بزرگ دانلود کن، نصبش کن، اجرا کن، منتظر به‌روزرسانی بمان و گاهی پیش از رسیدن به گیم‌پلی معنادار حساب بساز.
یک بازی مرورگری می‌تواند این مسیر را به یک لینک کاهش دهد.
این موضوع نحوهٔ اشتراک‌گذاری و تست نمونه‌های اولیه را تغییر می‌دهد. توسعه‌دهنده می‌تواند یک نسخه منتشر کند، URL بفرستد، فرد دیگری را فوراً وارد همان نسخه کند، بازخورد بگیرد و تکرار بعدی را منتشر کند، بدون اینکه از تست‌کننده بخواهد بستهٔ جدیدی را دستی نصب کند.
این مزیت برای بازی‌های آزمایشی و توسعهٔ مستقل اهمیت ویژه‌ای پیدا می‌کند. مرورگر فقط یک محیط اجرا نیست؛ یک سیستم توزیع هم هست.
مرورگر هنوز کجا می‌بازد
این پژوهش مرا قانع نکرد که مرورگرها جای پلتفرم‌های بومی بازی را گرفته‌اند. نگرفته‌اند.
چند محدودیت همچنان مهم‌اند:
- حجم بزرگ assetها. وقتی بازی به دانلود اولیهٔ بسیار بزرگی نیاز دارد، دسترسی فوری دیگر فوری به نظر نمی‌رسد.
- فشار حافظه. مرورگرها باید در کنار تب‌های دیگر و سیستم‌عامل کار کنند و رفتار حافظه نسبت به یک فرایند بومیِ اختصاصی کمتر قابل‌پیش‌بینی است.
- محدودیت‌های حرارتی موبایل. حتی یک بازی سه‌بعدی که از نظر فنی درست کار می‌کند، ممکن است در یک جلسهٔ طولانی به‌شدت دچار محدودسازی حرارتی عملکرد شود.
- تفاوت بین مرورگرها. گرافیک، صدا، pointer lock، رفتار fullscreen، کنترلرها و ویژگی‌های عملکردی کاملاً یکسان نیستند.
- آماده‌سازی شیدر و دارایی‌ها. اگر خط پردازش با دقت طراحی نشده باشد، کامپایل یا بارگذاری هنوز می‌تواند مکث‌های قابل‌مشاهده ایجاد کند.
- محدودیت‌های آفلاین و ماندگاری محلی. اپلیکیشن‌های بومی همچنان کنترل مستقیم‌تری روی نصب‌های بزرگ محلی و فایل‌ها دارند.
- امنیت رقابتی. وقتی کلاینت یک اپلیکیشن وب باشد، ضدتقلب جدی و فرض کلاینت متخاصم بسیار دشوارتر می‌شود.
این محدودیت‌ها مهم‌اند، چون مشخص می‌کنند بازی‌های مرورگری امروز در کجا قوی‌ترند: بازی‌هایی که از دسترسی فوری، تکرار سریع، توزیع چندسکویی و بودجهٔ قابل‌کنترل برای دارایی‌ها و زمان اجرا سود می‌برند.
AI حلقهٔ نمونهٔ اولیه تا URL را بسیار کوتاه‌تر می‌کند
AI در اینجا مرتبط است، اما نه چون به‌شکل جادویی یک جمله را به بازی کامل و باکیفیت تبدیل می‌کند. مزیت واقع‌بینانه‌تر، سرعت تکرار است.
توسعهٔ مدرن بازی شامل کارهای کوچک زیادی است که در مجموع پرهزینه‌اند: راه‌اندازی ماشین‌های حالت، ساخت نماهای دیباگ، نوشتن تست، آزمایش رفتار دشمن، ساخت قالب داده برای حرکت‌ها، بازآرایی کد ورودی، نمونه‌سازی شیدرها، بررسی باگ‌های فیزیک و متصل کردن محتوای موقت.
AI می‌تواند بسیاری از این چرخه‌ها را کوتاه کند. وقتی با توزیع وب ترکیب شود، گردش کار به‌طور غیرمعمولی مستقیم می‌شود:
idea -> prototype -> deploy -> open URL -> test -> iterateمرورگر همین حالا استقرار را سریع می‌کند. AI می‌تواند سمت پیاده‌سازی همین چرخه را هم سریع‌تر کند.
محدودیت مهم این است که تولید سریع جای سلیقه یا اعتبارسنجی را نمی‌گیرد. یک کنترلر مبارزهٔ تولیدشده می‌تواند از نظر ساختاری اشتباه باشد. زمان‌بندی انیمیشن هنوز به قضاوت انسانی نیاز دارد. فیزیک هنوز به دیباگ نیاز دارد. عملکرد هنوز باید اندازه‌گیری شود. AI هزینهٔ امتحان کردن ایده‌ها را کاهش می‌دهد؛ اما نیاز به تصمیم‌گیری دربارهٔ خوب بودن ایده‌ها را از بین نمی‌برد.
این برای توسعه‌دهندگان وب چه معنایی دارد
مرز بین توسعهٔ وب و توسعهٔ بازی کمتر و کمتر صلب می‌شود.
یک بازی مرورگری جدی اکنون می‌تواند از ابزارهای آشنای وب استفاده کند و در عین حال به مفاهیم کلاسیک مهندسی بازی نیاز داشته باشد:
- گام‌های ثابت شبیه‌سازی؛
- ماشین‌های حالت؛
- بافر ورودی؛
- گراف‌های انیمیشن؛
- پرس‌وجوهای فضایی؛
- فیزیک؛
- بودجهٔ فریم؛
- مدیریت منابع GPU؛
- زمان‌بندی صدا؛
- سیستم‌های قطعی.
در همان حال، توسعه‌دهندگان بازی که مرورگر را هدف می‌گیرند چیزهایی را به دست می‌آورند که وب از قبل در آن‌ها بسیار قوی است: URLها، استقرار فوری، تحویل از طریق CDN، به‌روزرسانی سریع، تله‌متری، سیستم حساب کاربری، رابط‌های واکنش‌گرا و اشتراک‌گذاری بدون اصطکاک.
این پژوهش مدل ذهنی خودم را تغییر داد. دیگر بازی‌های مرورگری را عمدتاً نسخه‌های ساده‌شدهٔ بازی‌های بومی نمی‌بینم. مرورگر را پلتفرم بازیِ هرچه توانمندتری می‌بینم که مجموعهٔ متفاوتی از نقاط قوت دارد: توزیع فوری، تکرار سریع، قابلیت‌های سه‌بعدی جدی‌تر و جدی‌تر، و یک اکوسیستم توسعهٔ موجود بسیار بزرگ.
وب فقط در نمایش بازی‌هایی که جای دیگری ساخته شده‌اند بهتر نمی‌شود. به‌طور فزاینده‌ای دارد به جایی تبدیل می‌شود که سیستم‌های جدی بازی می‌توانند مستقیماً طراحی، پیاده‌سازی، تست، توزیع و بازی شوند.