AmirSامیرحسین شاکرنژاد
بازگشت به پروژه‌ها

GREED

بازی چندنفره‌ای که در آن زمان خروج را خودتان انتخاب می‌کنید.

GREED پروژهٔ شخصی من است؛ از قوانین بازی تا شبیه‌سازی، ارتباط با سرور و رابط کاربری را خودم ساخته‌ام. ظاهر بازی به بازی‌های مار شبیه است، اما تصمیم اصلی چیز دیگری است: همین حالا با آنچه جمع کرده‌اید خارج شوید یا برای بیشتر به دست آوردن بمانید؟ اندازهٔ میدان با تعداد بازیکنان تغییر می‌کند و قدرت بازیکن هم سقف دارد تا دارایی بیشتر به معنی شکست‌ناپذیری نباشد.

مسئولیت من
طراحی بازی، برنامه‌نویسی کلاینت و سرور، ارتباط هم‌زمان و رابط کاربری
همکاری
پروژهٔ شخصی
سال
2026
وضعیت
در حال توسعه
حوزه‌ها
سیستم بازی · نرم‌افزار · زیرساخت · امنیت
ابزارها
TypeScriptReactPixiJSViteZustandFastifyWebSocket (binary)Rust · napi-rsPostgreSQLRedisDockerTurborepo

با چیزی ارزشمند برای محافظت وارد شو، آشکارا باارزش‌تر شو، و تصمیم بگیر همین حالا فرار کنی یا یک نبرد دیگر را ریسک کنی.

وعدهٔ بازی به بازیکن، از سند طراحی GREED

ایده

دارایی شما فقط امتیاز نیست؛ اندازهٔ بدنتان و خطری که تهدیدتان می‌کند هم به آن بستگی دارد. برای ذخیره کردن دارایی باید توقف کنید، جهت حرکت را ثابت نگه دارید و چهار ثانیهٔ خروج را زنده بمانید. اگر از بین بروید، دارایی‌تان در میدان پخش می‌شود و همه می‌توانند برای جمع کردنش رقابت کنند؛ نه فقط بازیکنی که شما را شکست داده است.

با جمع کردن دارایی، رشد بازیکن دیده می‌شود؛ اما قدرت او به همان نسبت زیاد نمی‌شود و سقف مشخصی دارد. آیتم‌های تزئینی هم فقط ظاهر را عوض می‌کنند و روی برخوردها اثری ندارند.

محاسبات بازی روی سرور انجام می‌شود

HTTPSbinary WSinternal WSBrowserReact · PixiJSFastify APIauth · queue · profileRealtime gatewaybinary WS · admissionAuthoritative roomsingle writer · 30 HzEnginedeterministic · TS ⇄ RustPlatform serviceseconomy · stats · ranksHash-chained journaldual receiptsPostgreSQLauthorityRediscoordination · cacheintentsnapshots · deltas (15 Hz)
مرورگر فقط فرمان بازیکن را می‌فرستد؛ نمی‌تواند موقعیت، دارایی یا نتیجهٔ برخورد را تعیین کند. هر اتاق بازی، شبیه‌سازی را ۳۰ بار در ثانیه اجرا می‌کند و وضعیت بازی و تغییرات آن را ۱۵ بار در ثانیه، با یک پروتکل باینری نسخه‌دار، برای بازیکنان می‌فرستد.

بخش‌های فنی بازی

  1. 1حرکت و مدل بدن

    کلاینت و سرور از محاسبات مشترک با ممیز ثابت استفاده می‌کنند تا نتیجه یکسان باشد. افزایش سرعت فقط از جرم بدن کم می‌کند و مقدار پول را تغییر نمی‌دهد.

  2. 2حالت رقابتی و تمرینی

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

  3. 3پیشرفت بدون برتری در بازی

    بازیکن با بازی کردن و انجام چالش‌ها امتیاز تجربه، نشان و آیتم‌های ظاهری می‌گیرد. این پیشرفت، قدرت یا ویژگی‌های فیزیکی او را بیشتر نمی‌کند.

  4. 4ثبت و کنترل جابه‌جایی پول

    پول در بسته‌های تغییرناپذیر جابه‌جا می‌شود تا مقدار کل آن حفظ شود. رویدادهای پایانی در دو دفتر ثبت با زنجیرهٔ هش نوشته می‌شوند. خروج بازیکن فقط بعد از ثبت هر دو رسید تأیید می‌شود.

  5. 5کنترل سوءاستفاده

    فرمان‌ها ترتیب و دورهٔ اعتبار مشخص دارند و نتیجه‌ای که کلاینت تعیین کرده باشد پذیرفته نمی‌شود. بلیت ورود یک‌بارمصرف است و درگاه ارتباطی هم تعداد درخواست‌ها و فشار ورودی را محدود می‌کند.

  6. 6مدیریت و پایش سرویس‌ها

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

دو نسخهٔ شبیه‌سازی با نتیجهٔ یکسان

موتور شبیه‌سازی را با TypeScript و بدون وابستگی به نمایش تصویر نوشته‌ام. یک نسخهٔ Rust هم از طریق napi-rs به Node متصل است. هر دو نسخه با ورودی‌های یکسان آزمایش می‌شوند تا نسخهٔ سریع‌تر همان نتیجهٔ نسخهٔ مرجع را بدهد.

وضعیت فعلی

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

فریم‌ها