سوالاتی در مورد طراحی گیم سرور

با سلام
در یک گیم آنلاین که هزاران نفر مشغول بازی اند ، بهترین راه حل برای ذخیره سازی وضعیت بازیکنا(چقدر حرکت کرد کجا حرکت کرد ، امتیازش و … ) چی هست ؟
اگر دیتابیس هست چه دیتابیسی پیشنهاد میکنید ؟
اگر دیتابیس نیست بهترین راه حل چه چیزی است ؟

سرور های بازی بیشتر state در memory ذخیره میکنند و اطلاعات هر چند ثانیه یک بار روی database ذخیره میکنند
به این سرور ها سرور های stateful گفته میشه
ارلنگ برای این کار خیلی خوبه

2 پسندیده

درود و تشکر
خودم هم تقریبا همچین فکری داشتم فقط فکر اینکه چطور از نودهای مختلف به یک state دسترسی داشته باشم کمی فهم قضیه رو برام دشوار کرده بخصوص اگر از rpc استفاده کنم برای این قضیه نمیدونم چقدر ممکنه تاخیر بابت این قضیه داشته باشه .
مثلا این حالت رو در نظر بگیر که با Agent اطلاعات لازم رو تو حافظه نگه دارم و از یک نود دیگه بخوام به اطلاعاتی که در Agent نود قبلی ذخیره شده دسترسی پیدا کنم . آیا این کار به نظر تو راه خوب و عاقلانه ای هست ؟
در مورد استفاده از چیزایی مثل redis نظرت چیه که بخوام از طریق اونها در حافظه ذخیره کنم ؟

در سیستم های stateful داده رو از نود ها تقسیم نمیکنی بلکه کاربر و همیشه میبری به نودی که داده مخصوصش را داره
یعنی اگه مثلا من با شما دارم بازی میکنم تمام اطلاعات این بازی در یک نود ذخیره میشه . و ما هردو به این نود فرستاده میشیم
برای این کار این بازی یک هش داره و هر کسی میخواهد به این بازی بیاد با همین هش به نود که داده اونو داره فرستاده میشه

2 پسندیده
2 پسندیده

خیلی ممنون بابت پاسخ

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

بله دقیقا

اینجاست که کار پیچیده میشه و باید سیستم بتونه به صورت دینامیک لود تقسیم کنه (rebalancing) سیستم هایی مثل orleans این کارو انجام میدهند ولی تو بیشتر scale که آدم ها game سرور دارند با این مشکل بر نمیخورند

1 پسندیده

حالا در مورد نودی که کاربر قراره هدایت بشه :
خوب اینه که آدرس نود رو یجورایی تو طرف کاربر ذخیره کنیم تا برای هر درخواستی آدرس نود این رو نگردیم
یا هربار درخواست داد نودی که قراره بهش هدایت بشه رو بگردیم و هدایت کنیم ؟
برای اینکار باید لایه ای که در جلو وجود داره برنامه نویسی بشه ؟ آیا نمیشه از یه چیز آماده شبیه nginx استفاده کرد و … ؟

میتونی این اطلاعات نود و cache کنی

با هردو روش میشه

1 پسندیده

مثل همیشه دستت درد نکنه که هروقت هر سوالی پرسیدم تا تونستی کمک کردی واقعا ممنون
تا پیش آمدن سوالات جدید بدرود :sweat_smile:

1 پسندیده

در مورد مواردی که فرمودید یک سری تحقیق کردم و تا الان تونستم یک نمونه خیلی ساده از چیزی که در ذهنمه پیاده کنم فقط الان با یک مشکل دیگه مواجه شدم .
اگر یک نود به هر دلیلی از کار افتاد :
-راه حل اول اینه که State در دیتابیس ذخیره بشه ( چه نوع دیتابیسی رو پیشنهاد میکنید ؟ - بعد از اینکه دیگه State لازم نبود همون لحظه از دیتابیس پاک کنم خوبه ؟ )
-راه حل دوم که به ذهنم اومد اینه که State در Mnesia ذخیره بشه ( یکم زمان زیادی میخواد تا دوباره از فایل بره داخل رم )


یک سوال دیگه هم دارم که اینه :
ممکنه کاربر با فرستادن اطلاعات غلط یا دستکاری بخواد که تقلب کنه برای همین باید اینها رو چک کنم و یکم زیادم هستن .حالت زیر رو در نظر بگیرید :

کاربر درخواست میفرسته
در سرور چک میشه که اطلاعات درستن غلطن نسبت به بقیه player ها و … و بر اساس اون state رو ویرایش میکنه . تمام اینها در یک برنامه میشه ! یعنی از ذخیره یا ایجاد یک state جدید تا الگوریتم ها و درخواست ها و …

کاربر درخواست میفرسته
بعد از api وارد یک لایه دیگه میشه که چک میکنه اطلاعات بازی درستن درست نیستن غلط نیستن ، با اطلاعات بقیه player ها سازگاری داره یا نه و …؟ بعد از پردازش اطلاعات و اجرای الگوریتمها ، state رو که شبیه key-value هست تغییر میده ، یعنی میان state و api یک لایه دیگه وجود داره که کارش پردازش داده هاست و بر اساس اونها state رو تغییر میده ، ذخیره کردن و خوندن از دیتابیس رو هم میخوام تو همین لایه پیاده سازی کنم تا بتونم side effect در state رو به کمترین مقدار ممکن کاهش بدم

کاربر درخواست میفرسته
بعد از api وارد یک لایه دیگه میشه ، در این لایه براساس اون اطلاعات state جدید ایجاد میشه ویرایش میشه در دیتابیس ذخیره میشه و … یعنی api جداست اما state و پردازش اطلاعات و ذخیره در دیتابیس و … همشون در یک لایه انجام میشن که اینم میترسم کلا state رو بیاره پایین

در حالت اول همشون داخل خود api انجام میشن
در حالت دوم پردازش-الگوریتم ها و state و api جداست یعنی سه لایه دارم
در حالت سوم api جداست اما الگوریتم ها(پردازش و ذخیره در دیتابیس و …) و api همه داخل یک لایه ان

ببخشین یکم طولانی شد ، بنظر شما کدوم بهتره ؟ یا من اشتباه میکنم و راه بهترتری وجود داره ؟(نمونه ای که پیاده کردم در حالت دوم هست اما یکم زیادی پیچیده شده و …)

روش دوم از همه scalable تره اما من پیشنهاد میکنم اول با ساده ترین حالت شروع کن و وقتی اون برای کارت مشکل داشت اون مشکل حل کن تا از اول سیستم پیچیده کنی

در مورد database هم mnisia بد نیست ولی من cassandra برای این کار ترجیح میدم

بجای اینکه یک لای برای تقلب بنویسی سعی کن بازی و طوری بنویسی که اصلا نشه تقلب کرد

1 پسندیده

منظورتون اینه طرف کلاینت داده قبل از ارسال داخل بازی رمز بشه ؟

منظورم اینکه تو منطق بازی جلوی تقلب بگیری
نگاه کن به

making illegal states unrepresentable

1 پسندیده

اخه اون وقت طرف کلاینت دسترسی داره میتونه عوض کنه . هرچقدرم محکم کاری کنم بازم یه راهی هست عوض کنه فک کنم

ببخشید یکم بی ربطه به موضوع
گوگل سرویس گیمینگ خودشو معرفی کرد
خبر خوب Software stack این سرویسه :heart:
Stadia

2 پسندیده