Turnkey Chat & Social Module Development for Games
We build multiplayer chats and social modules that don't break under load and avoid race conditions with game logic. With over 7 years of experience in game dev and 30+ completed projects, we know how to build a real-time layer that withstands peak concurrent users without RTT degradation.
Why a single channel chat is a bad idea?
The most common mistake is using one transport channel for both game events and chat messages. In Photon Realtime, each channel has FIFO guarantee within itself, but not between channels. If player movement RaiseEvent codes and text messages go through channel 0, a spike in chat activity increases position latency to 200–300 ms even with good ping. Solution: allocate a separate unreliable channel for chat with low priority and a reliable channel for system messages (kick, ban, invite).
What's included in the work?
- Architectural documentation (data schema, channels, priorities)
- Integration of Photon Chat or a custom server
- Implementation of message history, pagination, TTL cleanup
- Moderation (ML filter, rate limiting, mute/ban)
- Social graph (friends, guilds, invitations)
- Push notifications (FCM, WNS) via an async queue
- Load testing with bots on headless Unity
- Source code, README, migrations, team training
Where first implementations typically break
The second problem is history storage. Many teams store chat history directly in the Photon room via CustomRoomProperties, which works until the 1 KB property limit is exceeded. After that, messages are silently lost on the client. The correct approach: offload history to a separate microservice with PostgreSQL or Redis Streams, and keep only a pointer to the last read offset in the room.
Third pain is real-time moderation. Naive client-side RegExp filtering is bypassed in seconds. Server-side validation via Photon WebHooks v2 adds latency to every message. A working compromise: asynchronous post-moderation with instant message display for the sender and delayed delivery to others via a 50–100 ms buffer, during which the ML filter runs.
How to choose between Photon Chat and a custom server?
| Solution | Latency | Scalability | Flexibility | Cost |
|---|---|---|---|---|
| Photon Chat | <50 ms | High (ready infrastructure) | Low (only basic channels) | License + usage |
| Custom server (Node/Go) | <50 ms | Depends on implementation | Full (roles, guilds, analytics) | Development + hosting |
If your project is mid-core with guilds, custom roles, and moderation, a custom server pays off through control. For simple casual games with a single chat, Photon Chat is sufficient.
Building the social layer on top of the game session
Chat is the visible part. Underneath, you typically need: friends list, invites, guild/clan system, online/offline status, notifications. Photon offers Photon Chat as a separate SDK with its own servers—it solves basic tasks (public channels, private messages) but doesn't support custom roles and access rights. For games with guilds, this limitation is critical.
A typical architecture we use for mid-core projects: Photon Chat for real-time delivery + a custom REST API on Laravel/Node for managing structures (guilds, roles, mute/ban), PostgreSQL for persistence, Redis Pub/Sub for broadcasting events between API instances. The Unity client subscribes to a Photon Chat channel by guild ID, and metadata (name, avatar, members) is fetched via REST when entering the lobby.
On one project—a mobile battle royale with 100 players—we encountered a spike in Photon Chat connections when 80+ players entered the match lobby simultaneously, causing the EU-West region to crash about once a week. We fixed it with exponential backoff on the client (from 500 ms to 8 s, jitter ±200 ms) and lazy subscription: the team channel subscribes only after the roster is confirmed, not at the moment of JoinRoom. This reduced registration load by 40%.
What tools do we use?
For Unity projects, the main stack: Photon Chat SDK, Photon Realtime for game events, Mirror Networking or Netcode for GameObjects as alternatives for p2p setups. The chat server side uses Photon WebHooks v2 for event hooks plus a custom microservice for business logic. Learn more in the Photon Chat documentation.
For cross-platform projects (PC + Mobile + Console), support for OpenID Connect is important for unified authentication. The social graph (friends, blocks) is typically implemented via a separate table with a self-referencing FK and an index on (user_id, friend_id, status)—without it, the query "is any of my friends online" for a list of 500+ people results in a full scan.
Push notifications for out-of-game messages: Firebase Cloud Messaging for Android/iOS, WNS for Windows. Integration via a queue so that peak notification traffic does not block the main API.
Work stages for the module
First, we analyze the requirements: channel types, maximum concurrent users, history requirements, need for moderation, platforms. At this stage, we determine whether Photon Chat out of the box is enough or a custom backend is needed.
Then we design the data schema: tables chat_rooms, chat_messages, chat_members, indexes, TTL policy for old messages. Simultaneously, we design the real-time layer architecture.
Development proceeds iteratively: first basic message exchange, then history and pagination, then roles and moderation. Each stage is closed with integration tests on a real Photon environment.
Load testing is a separate stage. We simulate peak concurrency using Photon Load Balancer plus custom bots on headless Unity instances.
| Task scale | Estimated timeline |
|---|---|
| Basic chat (single channel, no history) | 1–2 weeks |
| Chat with history + private messages | 3–4 weeks |
| Full social module (friends, guilds, notifications) | 6–10 weeks |
| Custom server + moderation + analytics | 10–16 weeks |
The cost is calculated individually after analyzing the requirements and current project architecture. Ready to discuss your project? Contact us—we'll estimate timelines and cost for turnkey chat development.
Typical mistakes in self-implementation
Storing user_id only on the client—the server must verify identity via a token, otherwise any packet can be spoofed. Not implementing server-side rate limiting—10 messages per second from one client can bring down a channel. Using a synchronous DB query for each incoming message instead of batching—at 1000 messages/s, that's 1000 INSERT/s, which kills Postgres without connection pooling and bulk inserts. Forgetting ON DELETE CASCADE on member tables when deleting a room—leaves orphaned records that only surface during audits.
Order chat development—get a ready solution with documentation and support. We guarantee stability under load and a transparent process.