Agentic Gaming Platform
Real-time multiplayer, live chat and AI assistants are usually three separate systems bolted together. Here they are one: agents talk to the application's own services rather than sitting beside them as a chatbot, and everything — a move, a message, a match invitation — travels the same socket.
- 1
- event stream behind gameplay, chat and agents
- 4
- authentication paths: JWT, OAuth, Google SSO, 2FA
What it is
A platform built around live multiplayer games with the social layer that makes them worth returning to: matchmaking, rankings, friends, and chat that stays in sync while you are playing rather than living in a separate tab.
It runs on Django with an ASGI server, so HTTP and WebSocket traffic are served by the same application. The game state, the chat and the presence information are not three back ends pretending to cooperate — they are one, which is what makes a match invitation arriving mid-conversation feel like part of the same product.
Agents that use the product, not agents bolted onto it
The usual way to add AI to an application is to put a chat window in the corner that can answer questions about it. That is a different product wearing the same colours: it cannot do anything, because it has no access to the things the application can actually do.
The design here is the inverse. Agents are given the application's own services as capabilities and act through them, so an assistant is a participant with the same reach as a user rather than a commentator on the side. That is also why the event stream matters — an agent that acts has to observe, and both happen over the same connection everyone else is on.
Authentication worth the name
Four ways in, all landing on the same session model: password credentials issuing JSON Web Tokens, OAuth, Google single sign-on, and time-based one-time passwords as a second factor. The 2FA is the real thing — secrets provisioned to an authenticator app by QR code, and verified server-side on each login, rather than an email with a six-digit number in it.
Doing this in a platform where a WebSocket connection outlives the request that opened it is more interesting than it looks: the socket has to be authenticated at handshake and then trusted for its lifetime, which means the identity attached to a connection has to be established before any game or chat traffic is allowed to flow over it.
- Token-based auth on the REST surface, carried through to the socket layer rather than re-invented there.
- TOTP second factor with QR provisioning, verified server-side.
- Matchmaking, rankings and social graph as first-class services, not features grafted onto the game loop.
Built with
- Django
- Django REST Framework
- Channels
- Daphne
- React
- WebSockets
- SimpleJWT
- PyOTP
Not hosted: a stateful ASGI application with live connections. Source is public.