MOBA-Style Game Client

Disclaimer

This project was built as a close study of an existing commercial game, so out of respect for their IP, no images or videos will be shown publicly.

About

Full-featured MOBA-style game client prototype with custom client-server networking, real-time chat system, friends list, profile customization, custom rooms, complete playable character ban/pick phase with polished UI. Solo 3-month project pre-industry and first time using Unity.

History

I love playing PC MOBA games and daydreamed about tossing in characters from anime or other games with unique abilities. Planned a full MOBA with custom characters, then my friend showed me Unity (perfect for prototyping). Realized every MOBA starts with that lobby hub (news, store, chat, queues), so I dove into building the client first.

SubTasks

• Network
• Chat System
• Profile and Friends
• UI Prefabs with Audio and VFX
• Persistent Settings
• Animation Control
• Custom Game Rooms with State Machine
• Game Modes

Challenges

Networking & Client-Server Architecture

Needed a full client-server flow with an authoritative server so multiple clients could interact through a single MOBA-style game client, built as a solo project before any industry experience.

Approach

• Created a dedicated server project instead of compiling client and server from one solution with macros, and factored shared message definitions into common modules to keep networking code consistent across both.
• Evaluated Unity's low-level and high-level networking APIs and chose the UnityEngine.Networking HLAPI to ship faster while learning core networking patterns.
• Implemented a configurable server host (user-specified port, displayed IPv4) so clients could connect using that address, making it easy to relocate or restart the server without code changes.

Lessons & Future Improvements

• Initial implementation sent messages immediately on events without explicit replication strategy; if revisiting this today, I would introduce separate replication instances for chat, profile/status, custom game room search, and ban/pick.
• Ban/pick would run on a high frequency, authoritative channel to guarantee consistency, while lower priority systems (chat, profile, room search) would use less frequent replication to reduce traffic and simplify debugging.

Lobby / Custom Room System Design

Needed a custom room system that supported multiple game modes (Blind Pick, Draft Pick with ban/pick phase, All Random) with room metadata (name, password, mode, team/spectator sizes, owner) and live state sync for bans, picks, swaps, and chat between clients and an authoritative server.

Approach

• Implemented a CustomRoom type to represent a single room and a CustomRoomDatabase manager attached to a Unity object to own all active rooms, route server messages, and drive state transitions (lobby → ban → pick → ready).
• Encoded per-mode rules inside the room logic (e.g., no duplicate champions per team in Blind, structured ban/pick turn order in Draft, automatic random assignment in All Random), and exposed room searches over name/mode so players could find and join the right match.

Lessons & Future Improvements

• Current design packs all modes into one room class, making new modes hard to add. Next iteration would introduce a base Room with create/join/destroy and per-mode subclasses to handle ban/pick and flow rules, following an OO strategy style.
• Group chat handling lives inside the room; this should be pushed into a dedicated chat system with a clean API, so the room only triggers chat events.
• Several values (like timers) are hard-coded. These should be moved into data tables/config to let designers tweak timings without code changes.

Client UI & Platform Polish

Needed a non-blurry, modern UI for a desktop MOBA-style client, with custom controls, persistent settings, and a borderless window that behaved like a real game launcher instead of a stock Unity window.

Approach

• Replaced legacy UnityEngine.UI text with TextMesh Pro as the primary text system to improve sharpness and styling, and built custom UI prefabs (buttons, dropdowns, toggles, radio buttons) plus a small UI animation controller for tab selection and hover/press feedback using particles and Unity's video API for the login animation.
• Implemented persistent settings and “remember my username” by caching a config file in the user's Documents folder (resolution, audio, username, disable login animation/music) and loading it on startup.
• Created a Windows-specific bootstrap class that calls into OS APIs to create a borderless window and fully support runtime resolution changes from the in-client options menu.

Lessons & Future Improvements

• Current approach requires manual replacement of assets like login music/animation. A next step would be to add a lightweight patch/update pipeline where the client checks for updated assets on startup and downloads them into a local cache, avoiding manual file edits.
• Prefab variants and more data-driven UI (e.g., JSON or ScriptableObjects for control themes and animations) would make it easier to maintain multiple visual styles and tweak UX without code changes.