شب بازی فقط یک نسخه دیجیتالی دریافت کرد: عرشه

الهام بخش “عرشه” از وضعیتی ناشی شد که بسیاری از ما تجربه کرده ایم. تصور کنید که برای یک شب بازی با دوستان خود جمع می شوید ، فقط برای درک اینکه هیچ کس کارت های لازم را ندارد. ناامید کننده ، درست است؟ این معضل ایده استفاده از فناوری را برای ایجاد راه حل برانگیخت.

هدف اصلی “عرشه” فراهم کردن یک محیط بازی دیجیتال کاربر پسند و تعاونی برای انجام بازی های کلاسیک است که معمولاً با کارت روی کاغذ بازی می شدند. یکی از ویژگی های برجسته “عرشه” توانایی منحصر به فرد آن برای اختصاص یک دستگاه به عنوان “جدول” (عرشه با نام مستعار) است. با قرار دادن این دستگاه در وسط گروه ، همه بازیکنان می توانند شاهد وضعیت واقعی کارت ها باشند. این باعث می شود سطح جدیدی از غوطه وری باعث شود که آن را به یک تجربه واقعاً فریبنده تبدیل کند.

جریان بازی

ابتدا ، بیایید به نتیجه نگاه کنیم. من در مورد آنچه ممکن است UX مناسب برای چنین راه حلی باشد ، می دانم و در مراحل بعدی حل و فصل کردم (در اینجا ما از Android TV به عنوان جدول استفاده می کنیم):

1. اتاق را ایجاد کنید – برای ایجاد یک اتاق از تلویزیون ، موبایل ، میز یا LAPROT استفاده کنید.

1. به اتاق بپیوندید. دستگاهی که اتاق را ایجاد کرده است نیز می تواند شرکت کند ، یا فقط عرشه باشد.

1. بازی را شروع کنید! به محض اینکه بازیکنان کافی دارید ، میزبان می تواند بازی را شروع کند.

در این حالت ، تلویزیون میزبان و عرشه است. بازیکنان از تلفن های خود برای جابجایی استفاده می کنند و افراد دیگر می توانند به روزرسانی های بازی را در تلویزیون مشاهده کنند.

اجرای

طی مدت زمان تقریباً چهار ماه ، من عصرها و آخر هفته های هفته خود را به توسعه سه بازی اختصاص دادم: Tic Tac Toe ، Connect Four و Dixitt. سرانجام ، من آنها را در هر دو فروشگاه iOS و Android منتشر کردم. در اینجا چند جزئیات در مورد اجرای بازی آورده شده است.

لایه حمل و نقل

با توجه به اینکه می خواستم اطمینان حاصل کنم که برنامه می تواند در شبکه محلی اجرا شود و نیاز به برقراری ارتباط دو جهته و کم تأخیر بین شرکت کنندگان داشته باشد ، راه حل کاملاً آشکار بود-سوکت:

برای MVP تصمیم گرفتم که با Socket.io بروم. بعد از یک جستجوی سریع ، بسته هایی را برای DART پیدا کردم:

چرب-مشتری
سوریلر

اتاق بازی

اتاق بازی انتزاع پایه سکو است. هر بازی با یک میزبان شروع می شود و یک اتاق ایجاد می کند و از شرکت کنندگان و ناظران دعوت می کند. به محض تحقق محدودیت های بازی (به عنوان مثال ، حداقل تعداد بازیکنان مورد نیاز) ، میزبان می تواند بازی را شروع کند.

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

تجزیه قطعات:

• جزئیات بازی – این شرح بازی و IP اتاق است. این در کد QR تبلیغ می شود تا مشتریان بتوانند بررسی کنند که آیا از بازی پشتیبانی می کنند و می توانند به آن بپیوندند.
• اتاق بازی – بر اساس جزئیات بازی ایجاد شده ، ارکستر اصلی بازی است ، شرکت کنندگان را پیگیری می کند و وضعیت بازی را کنترل می کند
• شرکت کنندگان در بازی – لیست شرکت کنندگان با برخی از ابرداده ها
• نمایه شرکت کننده – مشخصات شرکت کننده در عرشه ، با اطلاعات پروفایل کاربر
• صفحه بازی – انتزاع پایه برای هر بازی
• حرکت بازی – تخته شامل لیستی از تمام حرکات بازی است که اعمال شده است.
• بازیگر بازی – موجودی که نقش شرکت کنندگان را در بازی توصیف می کند ، مانند “قرمز” یا “زرد” در Connect Four ؛
• میدان بازی – بازنمایی قسمت بازی ، یعنی 7 در 8 ماتریس برای Connect Four ؛

اتاق: ایجاد ، پیوستن ، شروع

در اینجا Gameroom Lifetime است:

عرشه / میز

عرشه یا جدول و همچنین مشتری ، مشترک به روزرسانی ها ، تنها تفاوت این است که سرور نمی تواند “حرکت” را اجرا کند.

در صورتی که دستگاه یدکی نداشته باشید می توانید بدون یک عرشه بازی کنید.

لطفاً توجه داشته باشید که دستگاه های تلویزیون Android منحصراً به عنوان “جدول” در بازی خدمت می کنند.

بسته ها

از ابتدا می خواستم اطمینان حاصل کنم که کد سرور سوکت می تواند به طور جداگانه اجرا شود و در ابر مستقر شود. بنابراین ، من برنامه را به 4 بسته جداگانه تقسیم کردم:

• مشترک – DTO مشترک و خدمات مشترک
• سرور – منطق سرور سوکت ، به مشترک بستگی دارد
• منطق مشتری مشتری – جیب ، به مشترک بستگی دارد
• UI – بسته برنامه UI Flutter ، به 3 ماژول دیگر بستگی دارد

ماژول های متداول ، مشتری و سرور هیچ وابستگی فلاتر ندارند و می توانند به عنوان بسته های جداگانه منتشر شوند.

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

حالت بازی

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

دولت از طریق پخش (Socket.io API) به کلیه مشتری های متصل پخش می شود.

حالت UI با redux

مشتری صرفاً یک نمایندگی در زمینه بازی است ، این یک تصمیم آشکار برای استفاده از Redux به عنوان یک معماری برنامه بود. هر صفحه بازی دارای دو عملکرد اساسی است:

1. زمینه بازی را بکشید
2. ارسال درخواست حرکت بازی

سوکت و ردوکس

قطعات جمع می شوند تا جریان بعدی را تشکیل دهند:

1. وقتی کاربر بازی را انتخاب می کند ، برنامه یک سرور و اتاق بازی سوکت ایجاد می کند و آنها را در دستگاه میزبان ذخیره می کند.
2. در عین حال دستگاه میزبان یک مشتری سوکت ایجاد کرده و به سرور که در همان دستگاه کار می کند متصل می شود.
3. Socket Server Board Game Board را به 2 مشتری (خودش و یک بازیکن دیگر) پخش کنید.
4. Socket Client یک صفحه بازی دریافت می کند و آن را به Middleware پخش می کند.
5. به روزرسانی Middleware حالت خاص بازی Redux ؛
6. به روزرسانی ویجت بازی بر اساس حالت جدید ؛
7. اکنون بازیکن می تواند ارسال کند move درخواست به سرور ، که از طریق Middleware & Socket Client به سرور و Gameroom Middleware پخش می شود.

API سوکت

برای ساده سازی ارتباط از طریق سوکت ، تصمیم گرفتم یک انتزاع مانند استراحت کنم. هر پیام از پشت که شامل مسیر است ، گسترش می یابد. مسیر معمولاً یک/roomId/* یا/roomId/gameID/* است. هنگامی که مشتری به اتاق متصل می شود ، آنها برای به روزرسانی از اتاق خاص برای بازی خاص مشترک می شوند.

class AppSocketMessage extends JsonEncodeable {
  final String messageId;
  final String path;
  final DateTime createAt;

  final JsonEncodeable data;

  AppSocketMessage.send(this.data, this.path)
      : messageId = Ulid().toUuid(),
        createAt = DateTime.now();

  AppSocketMessage._receive(this.data, this.createAt, this.messageId, this.path);

  @override
  Map toMap() {...}

  factory AppSocketMessage.fromJson(Map json) {...}
}

همه data ارسال شده AppSocketMessage رعایت کردن JsonEncodeable این تضمین می کند که می توان آن را به JSON تبدیل کرد.

پشتیبانی متقابل پلتفرم

فایده قابل توجه استفاده از Flutter این است که می توانید آن را بر روی سیستم عامل های مختلف از جمله Android و iOS اجرا کنید. با استفاده از تراشه های اپل M1/2 که از برنامه های iOS پشتیبانی می کند ، می توانید عرشه را حتی در MacBook خود اجرا کنید.

➡ متأسفانه ، Tizen / Samsung به توسعه دهندگان مستقل اجازه نمی دهد برنامه های خارج از ایالات متحده را منتشر کنند. در مورد Apple TV- این چیزی است که من قصد دارم بعداً به آن نگاه کنم.

طراحی

من می خواهم این نکته را برجسته کنم که تمام دارایی های بازی ، از جمله نماد برنامه ، نشان های دستیابی ، آواتارهای پخش کننده و کارتهای بازی Dixit ، همه چیز توسط Midjourney یا Dall-E ایجاد شده است.

بیان اینکه چقدر وقت ، تلاش و پول را صرفه جویی کردم ، من باعث صرفه جویی در زمینه تولید AI 🧑‍🎨 حتی می شوم ، حتی زمان قابل توجهی را صرف “تنظیم دقیق” آنها در FIGMA می کنم.

بعد چیست؟

اول از همه ، قدرت “عرشه” در سکو است. ➡ حرکت به جلو ، چشم انداز من این است که کد بازی را انتزاع کنید و آن را منبع باز کنید و علاقه مندان را ترغیب به توسعه و سوار شدن به بازی های خود کنند. هدف من این است که اطمینان حاصل کنم که اضافه کردن یک بازی جدید به سیستم عامل به یک فرایند بی دردسر تبدیل می شود. اگر علاقه مند به پیوستن به آزمایش های زودهنگام هستید با من تماس بگیرید me@getthedeck.com 🤝

من می خواهم پروتکل های جدید اتصال متقابل پلت فرم را کشف کنم تا ارتباط یکپارچه با دستگاه های اطراف را فراهم کنم. 🎮

اضافه کردن عوامل هوش مصنوعی وقتی که فاقد چند بازیکن هستید با شما بازی کنید

سرانجام ، من از چشم انداز Web3 شیفته می شوم. به بازیکنان نشان های NFT منحصر به فرد NFT برای دستاوردها ، مکان نشانگر داخلی باز کنید و گزینه های مناقصه ای را برای بازیکنان بزرگسال با ارزهای رمزنگاری کنید. چه کسی می داند چه تحولات مهیج در پیش است؟

بازدید

به GetTheDeck.com مراجعه کنید

بارگیری کردن

رمز منبع

سهم بسیار خوش آمدید! 🤝 ❤

پشته فنی

لیست ابزارهای مورد استفاده برای ارائه پروژه