https://virgool.io/feed/@khodadad.mahdavi6 fa 2026-06-10 14:58:50 https://files.virgool.io/upload/users/4011810/avatar/avatar.png?height=120&width=120 https://virgool.io/@khodadad.mahdavi6 https://virgool.io/@khodadad.mahdavi6/%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D9%BE%DB%8C%D8%B4%D9%86%D9%87%D8%A7%D8%AF%DB%8C-%D8%A8%D8%B1%D8%A7%DB%8C-%DB%8C%DA%A9-%D8%A8%D8%A7%D8%B2%DB%8C-%D8%A2%D9%86%D9%84%D8%A7%DB%8C%D9%86-%D8%A8%D8%A7-%D8%A7%D8%B3%D8%AA%D9%81%D8%A7%D8%AF%D9%87-%D8%A7%D8%B2-%D9%85%D9%88%D8%AA%D9%88%D8%B1-unity-%D9%88-nakama-uqe2sxa0y0v2 این مطلب بخشی از تمرین های درس معماری نرم‌افزار دانشگاه شهید بهشتی استAbstractThis report presents the software architecture of an online, server‑authoritative mobile game built with a Unity client and a Nakama backend (Go runtime). The two repositories—Unity application and Nakama server module—compose a cohesive system that provides deterministic turn‑based gameplay, matchmaking with a batched cadence, authoritative move validation, per‑turn deadlines, personalized state dissemination, and resilient rejoin behavior. The Architecture is documented using multiple ISO/IEC/IEEE‑42010‑aligned viewpoints (context, logical, process/runtime, information, and deployment), provide high‑level sequence and component diagrams, and outline a final‑form production architecture. I also survey alternative architectural stacks, summarize trade‑offs, and compare approaches across learning curve, scalability, control, and other criteria.1. IntroductionThis project implements a competitive, turn-based version of Tic-Tac-Toe for mobile. Two players share a 3×3 grid; X acts first and O responds, with turns alternating until one player forms a straight line of three marks along a row, column, or diagonal. If all cells are filled without such a line the result is a draw. The gameplay is intentionally strict: the server validates every move, enforces a 10-second per-turn deadline, and declares the opponent the winner on timeout or voluntary departure. Clients never “decide” outcomes; they render the authoritative state they receive and submit only move intents.The proposed architecture is a deliberately thin Unity client coupled to a Nakama backend that hosts the authoritative game logic in a Go runtime module. The client authenticates with Nakama over HTTP/gRPC and participates in matchmaking over a pool that is batched at 10-second intervals. Once matched, play proceeds on a persistent WebSocket channel where the server sends personalized snapshots including the recipient’s seat (seat_you), the next mover, the current board, an optional winning line, and the absolute deadline tick for the active turn. The client derives “your turn” purely from that snapshot and transmits moves as compact JSON messages. Robustness is ensured by a rejoin mechanism: if a device reconnects during an ongoing match, the client re-enters the match and resumes from the next snapshot without divergence.Content is delivered via Unity Addressables to separate code from art and layout. Core UI remains local for instant startup, while the gameplay prefab (the board and its cells) is hosted remotely behind a static endpoint. On launch, the client initializes Addressables, checks for catalog updates, and loads the latest board prefab before play. This arrangement supports rapid visual iteration and light gameplay UI changes without republishing the application.The architecture is documented and evaluated through several complementary viewpoints. The context view positions the Unity app, Nakama services, the matchmaker, and the content CDN, clarifying external dependencies and trust boundaries. The logical view decomposes the client into UI, networking, and gameplay orchestration components and the server into the matchmaker hook and the match handler, establishing responsibilities and interfaces. The process/runtime view traces the match lifecycle—pooling, seating, move validation, deadlines, and termination—at a fixed server tick rate that decouples transport jitter from rules enforcement. The information view specifies the minimal protocol—opcodes, payloads, and the semantics of authoritative snapshots—so that both correctness and client simplicity are maintained. The deployment view maps these concerns onto a concrete runtime: an Android build (IL2CPP, ARM64), a Nakama container with the Go plugin, and a static host for Addressables, with an optional reverse proxy and observability stack for production.Across these views the design goals remain consistent: fairness through server authority, determinism through single-source-of-truth snapshots, operability through containerized deployment and content hot-updates, and resilience through explicit rejoin semantics and time-bounded turns.2. System overview (context view)System OverviewKey external actors are the matchmaker and a static content CDN for Addressables. The database is not used during turn resolution (in‑memory match state) but can be used for summaries and live‑ops in future work.3. Logical viewLogical ViewResponsibilities:- Client: subscribe on the live socket, render authoritative snapshots, throttle input to your turn, manage rejoin, and fetch the remote board prefab.- Server: assign seats deterministically, validate moves, maintain per‑turn deadlines, and unicast personalized snapshots (including seat_you).4. Process/runtime view (match lifecycle)Sequence Diagram Of Online MatchThe handler runs at 5 Hz, advancing deadline_tick and enforcing a 10‑second per‑turn timeout. Personalized snapshots ensure both clients know their role and the current turn immediately.5. Information viewInbound: opMove with { "index": 0..8 }.Outbound: opStateopGameOver with:Personalized Snapshot Sent to Player From NakamaThe client treats every snapshot as authoritative; UI timers are derived from configuration (10 s) and can be made precise by including a server tick in future work.6. Deployment viewDeployment ViewOne command brings up the backend: docker compose up --build (multi‑stage build compiles and mounts the Go plugin). The client points to the server’s host/port and fetches remote gameplay content via Addressables.7. Selected implementation examples (illustrative snippets)7.1 Server: match creation from matchmaker7.2 Server: personalized snapshot (includes seat_you)7.3 Client: socket usage and state handling7.4 Client: Addressables bootstrap (catalog update + load board)8. Proposed final‑form architecture (Nakama + Unity)This section sketches an end‑state production architecture that extends the current minimal system with social, economy, competition, and live‑ops features—while preserving server authority.Full Backend and Game Using Proposed ArchitectureKey properties: authoritative writes via RPC/hooks, persistent storage for identity/economy, ranked leaderboards with seasonal resets, friends/clans for social retention, and operational endpoints and jobs for live‑ops. Addressables continues to deliver remote content updates.9. Alternative architectures9.1 Unity + PlayFab + Photon Realtime/Fusion (managed backend + managed realtime)- Description. Client uses Photon for realtime rooms and PlayFab for auth, data, and economy. High velocity with managed services; less control over server‑side game logic unless using Photon Server SDK separately.9.2 Unity + Firebase (Auth + Firestore/RTDB + Cloud Functions)- Description. Suitable for casual/async play. Realtime DB/Firestore events and Cloud Functions implement logic; not ideal for authoritative low‑latency realtime, but simple and scalable for turn‑based without sockets.9.3 Unity + Colyseus (Node.js) self‑hosted- Description. Game logic in Node.js rooms; good developer experience, full control, self‑hosted on Docker/K8s. Requires building social/economy or pairing with external services.9.4 Comparative tableCompression Table10. ConclusionThe Unity + Nakama architecture achieves a principled split of responsibilities: a thin, reactive client renders server‑authoritative state, while the backend ensures correctness, fairness, and resilience. The same extension points (RPCs, hooks, jobs, custom HTTP) can scale this minimal prototype into a full game backend with leaderboards, shops, storage‑backed identity and inventory, friends/clans, and parties—all while retaining deployer control and open‑source transparency.11. ReferencesHeroic Labs, “Nakama: Open‑Source Game Server”Unity Technologies, “Addressables,” ManualPhoton Engine Multiplayer ServicesMicrosoft Azure Playfab Multiplayer ServicesFirebase Services For GamesColyseus Multiplayer FrameworkAppendix A — Repositorieshttps://github.com/KhodadadMahdavi/SAC_Gamehttps://github.com/KhodadadMahdavi/SAC_NakamaServerAppendix B — Video Demonstration of the Final Gamehttps://www.aparat.com/v/azo13m5 khodadad mahdavi khodadad mahdavi Sat, 23 Aug 2025 12:47:06 +0330 https://virgool.io/@khodadad.mahdavi6/%D8%A2%D8%B4%D9%86%D8%A7%DB%8C%DB%8C-%D8%A8%D8%A7-15-%D9%85%D9%81%D9%87%D9%88%D9%85-%D8%AF%D9%86%DB%8C%D8%A7%DB%8C-%D8%A7%D9%85%D8%B1%D9%88%D8%B2-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-anb8erm1eg9m Infrastructure as Codeروشی برای مدیریت و پیکربندی زیرساخت های فناوری اطلاعات می‌باشد، در این روش برای تنظیمات و عملیات ها به جای تنظیمات دستی از کد استفاده می‌شود. این روش به تیم های فناوری اطلاعات امکان اتوماسیون عملیات ها و تنظیمات در ساختار های خود را می‌دهد و مزیت استفاده از آن بهینگی و ثبات در تمامی فرایند ها است.API Gateway & Service Meshیک API Gateway درگاه ارتباطی مرکزی یک سیستم microservice می‌باشد که درخواست های Client های مختلف را به microservice مورد مرتبط با درخواست ارسال می‌کند و همچنین وظیفه اطمینان حاصل کردن از احراز هویت درخواست دهنده و امنیت اطلاعات را بر عهده دارد.اصطلاح Service Mesh به نحوه مدیریت ارتباط و ارائه خدمات غیر متمرکز در microservice ها گفته می‌شود. هنگان استفاده از این روش هر microservice وظیفه ارتباط بین سرویس ها و همچنین برقراری امنیت اطلاعات و کنترل ترافیک درخواست ها بر عهده خود آن سرویس است که از طریق نصب یک proxy سبک در کنار آن سرویس ممکن می‌شود.CQRS (Command Query Responsibility Segregation)یک الگوی معماری در دنیای نرم‌افزار که هدف آن جداسازی دستورات و درخواست های ثبت و تغییر اطلاعات از دستورات و درخواست های خوانش آن اطلاعات در بخش های مختلف از نرم‌افزار است. دلیل پیداش این الگوری معماری نرم‌افزار در مشکلات مدل های سنتی تر مدیریت فرایند ها بر روی داده ها و اطلاعات می‌باشد. در مدل های سنتی به دلیل یکپارچه بودن پایگاه داده ها تمامی درخواست ها از جمله درخواست ثبت جدید اطلاعات و درخواست تغییر اطلاعات قبلی و درخواست خواندن اطلاعات همگی بر یک پایگاه داده اعمال می‌شدند که بخش مشکل ساز همین بخش است. از دلایل مشکل ساز بودن این طراحی می‌توان به فرکانس هر نوع درخواست جداگانه اشاره کرد، برای مثال درخواست های خواندن اطلاعات در مقایسه با درخواست ثبت اطلاعات جدید با فرکانس خیلی بیشتری استفاده می‌شوند پس درخواست ثبت اطلاعات ممکن است در پشت یک صف طولانی از درخواست های خواندن اطلاعات گیر بکند.Event-Driven Architecture (EDA)معماری مبتی بر رویداد یک نوع معماری سیستم های نرم‌افزار است که هنگام پیاده سازی و استفاده از آن ارتباط بین بخش های مختلف نرم‌افزار از طریق ارسال و دریافت پیام هایی به نام Event انجام می‌شود. یک Event یا رویداد در دنیای برنامه نویسی به یک بسته پیام گفته می‌شود که در شرایط خاصی که معمولا نام خود را نیز از همان شرایط خاص دریافت می‌کند، فراخوانی می‌شود و اطلاعاتی مبنی بر وضعیت پیش آمده و فرستنده پیام با خود همراه دارد. در این نوع از معماری نرم‌افزار تلاش بر این است که تا حد ممکن تعاملات میان مولفه های نرم‌افزاری از طریق ارسال و دریافت Event انجام شود که در عمل باعث کاهش وابستگی مولفه های نرم‌افزاری به یکدیگر خواهد شد.Serverless Architectureبرای درک و آشنایی با این مفهوم اول باید با مفهوم Server Architecture آشنا شد، در معماری با سرور تمامی فرایند های تنظیمات و مدیریت سخت افزاری سروری تا نرم‌افزار مستقر شده بر روی آن و وضعیت آن ها در شبکه اینترنت برای خدمت دهی توسط تیم تولید و توسعه انجام می‌شود. در معماری Serverless تخصیص منابع سرور و تنظیمات آن توسط شرکت ثالث ارائه دهنده خدمات ابری انجام می‌شود. در این معماری تیم توسعه نرم‌افزار کاربردی، محصول خود را در قالب توابع مختلف برنامه نویسی می‌کند و ارائه دهنده خدمات ابری منابع خاص برای اجرای این توابع را به آن ها تخصیص می‌دهد. پس در این مدل معماری نرم‌افزار توسعه یافته در اصل یک سری و گروه از Function های مستقر در فضای ابری هست که وظیفه مدیریت منابع و اجرای آن ها بر عهده یک ارائه دهنده خدمات ابری است.API-first Approachیک دیدگاه و نحوه نگرش به تولید محصولات نرم‌افزاری تحت وب می‌باشد که در این نگرش API های شما اولین چیزی هستند که طراحی می‌شوند و ساختار back-end و client شما برگرفته از این API های طراحی شده می‌باشد. هدف از این نوع نگرش به توسعه یک محصول تمرکز بر روی استفاده نهایی محصول و همچنین ارائه خدمات بهتر و کامل تر با قابلیت استفاده مجدد به کاربران سیستم نرم‌افزاری استDomain Driven Designیک روش طراحی نرم‌افزار که در آن محدوده مسئله که محصول نرم‌افزاری با هدف حل آن و یا ارائه خدمات در آن توسعه داده می‌شود بسیار اولویت بالایی در تصمیمات طراحی و تولید نرم‌افزار دارد. برای مثال اگر شما در حال توسعه یک نرم‌افزار مالی هستید، نگرش Domain Driven به شما کمک می‌کند تا با روش های مختلف مثل استفاده از دانش نخبگان این حوزه مالی بتواند به بهترین نحو مسائل خود را مدل سازی کنید و حیطه کاری نرم‌افزار شما در فرایند طراحی و تولید اولویت اول باشد.Hexagonal architectureمعماری شش ضلعی که با نام Ports and Adapters نیز شناخته می‌شود. یک نوع معماری سامانه های نرم‌افزاری هست که هدف آن جداسازی و کاهش ارتباط مستقیم هسته اصلی نرم‌افزار که قابلیت های کسب و کاری آن را ارائه می‌دهد با لایه های خارجی آن از جمله لایه ارتباطی کاربر و یا لایه پایگاه داده است.در معماری شش ضلعی هسته اصلی نرم‌افزار با تمامی ساختار های خارجی از طریق درگاه های مشخص (Ports) که درگاه های ارتباطی انتزاعی (Interface) هستند انجام می‌شود. این درگاه ها پروتکل های ارتباطی و نحوه ارتباط با هسته نرم‌افزار را تعیین می‌کنند.Event Sourcingیک الگوری طراحی و نحوه پیاده سازی رویداد ها درون نرم‌افزار است که مشابه نگهداری یک گزارش بسیار ریز از تمامی اقدامات زمان اجرای نرم‌افزار شما می‌باشد. در این روش نرم‌افزار شما به جای تغییر حالت برنامه به هر شکلی، آن را به صورت رویداد هایی که ثبت می‌شوند انجام می‌دهد. از این طریق شما می‌توانید تمام وقایعی که باعث وضعیت فعلی اجراایی نرم‌افزار شدند را از اول مجدد اجرا کنید و تک تک گام ها را در اختیار داشته باشید.با استفاده از این الگوری طراحی شما می‌توانید در هر زمان از اجرا به زمانی در گذشته برگردید و هیچ وضعیتی از برنامه برای کاربر از دست نخواهد رفت که در نرم‌افزار های مالی و تجاری یک مزیت بسیار مهم حساب می‌شود.Low-code/No-code platformsسکو های low-code و no-code مکان های برای توسعه نرم‌افزار با هدف کاهش کدنویسی مورد نیاز برای توسعه آن نرم‌افزار ها هستند. در سکو های low-code تلاش بر این است که با استفاده از یک سطح متوسط از انتزاعات بخش قابل توجهی از کدنویسی مورد نیاز برای توسعه یک نرم‌افزار حذف شود و توسعه دهنده با استفاده از روش های مختلف گرافیکی و کمی کدنویسی در سطح بالاتر نرم‌افزار مورد نیاز خورد را توسعه دهد. هدف سکو های no-code یک قدم فراتر رفتن و حذف کامل نیاز به کدنویسی برای توسعه نرم‌افزار هست که در حال حاضر نرم‌افزار هایی با هسته های ساده تر و کمتر شخصی سازی شده در آن ها توسعه داده می‌شوند.Business Process Management Systems (BPMS)سیستم های پردازش مدیریت کسب و کار، نرم‌افزار هایی هستند با هدف بهبود و بهینه کردن تمامی فرایند های یک کسب و کار و کاهش خطا های اجرایی و هزینه های تمامی این فرایند ها و هدف اصلی آن ها روز به روز بهتر شدن وضعیت مدیریت و اجرای فرایند ها در یک کسب و کار می‌باشد.برخی از این نرم‌افزار ها عبارتند از:monday.comCRM creatioNanonetspipedriveWrikeMessage Queue (such as Kafka and RabbitMQ)یک Message Queue مکانیزمی برای ارتباط و انتقال اطلاعات بین بخش ها و سرویس های مختلف یک معماری نرم‌افزاری گسترده هست این نرم‌افزار ها همچنین به عنوان یک حافظه موقت برای درخواست های سامانه و مسیریاب درون سامانه نیز استفاده می‌شوند.سامانه Kafka یک نرم‌افزار open source توسعه یافته توسط Apache Software Foundation هست که با هدف ارائه به عنوان Message Queue تولید شده است. این نرم‌افزار وعده عدم قطعی و از دست رفتن اطلاعات می‌دهد که برگرفته از طراحی گسسته و چند پایگاه داده ای آن می‌باشد.سامانه RabbitMQ نیز یک نرم‌افزار open source در رقابت با Kafka می‌باشد یک قابلیت های مشابهی ارائه می‌دهد با برخی معایب و مزیت ها در مقایسه با Kafka ، از مهمترین مزیت های آن می‌توان به پشتیبانی از پروتکل های Massaging بیشتر اشاره کرد.Container orchestration (such as Kubernetes)کانتینریزه کردن نرم‌افزار ها روشی برای بسته بندی گروه های ‌نرم‌افزاری در کنار هم در حین جداسازی بخش های منطقی مختلف آن ها است. Container orchestration در زمان نیاز به استقرار چند Container در کنار هم برای رسیدن به یک سیستم واحد مطرح می‌شود و به نحوه مدیریت ارتباط این Container ها به عنوان یک سیستم کامل که در کنار هم مستقر شده اند تا نیاز های مخاطب را پاسخ دهند گفته می‌شود. نرم‌افزار Kubernetes یک نرم‌افزار open source برای اتوماسیون استقرار و کانتینریزه کردن نرم‌افزار ها و مدیریت ارتباط آن ها به عنوان یک سامانه واحد است و در دنیای امروزی برای پیاده سازی سیستمی با استفاده از چند Container متفاوت بسیار بهتر از رقبا عمل می‌کند.Multi-Tenancy Architectureدر این مدل معماری نرم‌افزار و System Design سامانه های تحت وب، نسخه های مختلف نرم‌افزاری ارائه شده به کاربران مختلف برای عملکرد خود از سامانه های پایه ای مشترک استفاده می‌کنند. در این مدل معماری به هر نسخه نرم‌افزار نهایی ارائه شده به گروهی از کاربران یک Tenant یا مستاجر گفته می‌شود و چندین نرم‌افزار Tenant می‌توانند از یک سرس سامانه های پایه ای واحد خدمات دریافت کنند و به فعالیت خود به صورت مجزا با کاربرانی مجزا ادامه دهند.Enterprise Integration Patternsیک گروهی از الگو های طراحی که هدف آن ها توسعه نرم‌افزار هایی با ساده سازی ادغام نرم‌افزار های جدید و یا موجود دیگر با آن ها است. یک کتاب با همین نام توسط Gregor Hohpe نوشته شده است که در 65 الگوی طراحی در قالب 9 دسته مختلف معرفی شده اند که هرکدام به نوع خود به توسعه دهنده یک نرم‌افزار سازمانی کمک می‌کنند که نرم‌افزار خود را از پایه با قابلیت ادغام با دیگر نرم‌افزار ها توسعه دهد. khodadad mahdavi khodadad mahdavi Wed, 14 May 2025 22:25:48 +0330