Multiplayer Game Development Sample
Overview
This project is a sample implementation of a local-LAN multiplayer game built with open-source and self-hosted tools.
The goal of this project is to explore how a multiplayer game can be built using GDevelop for the game client, JSON Server for persistent game data, and Mosquitto MQTT for real-time communication between players.
This is primarily a learning and experimentation project. The goal is to develop a working multiplayer architecture while documenting the decisions, techniques, and problems encountered along the way.
Technology Stack
GDevelop
GDevelop is used to create the actual game client.
It handles:
- Game logic
- Player movement
- Maps and scenes
- Character sprites and animations
- User interface
- Communication with the backend services
- Processing multiplayer updates
The game is designed as a browser-based application, allowing it to run on desktop browsers and potentially mobile devices.
JSON Server
JSON Server provides a simple REST API and persistent data store.
It is used for information that needs to persist between sessions, such as:
- Player accounts
- Password hashes
- Character selection
- Player position
- Current room
- Other persistent player data
JSON Server is not intended to handle the real-time multiplayer communication. It provides the persistent data that the game can retrieve or update when necessary.
Mosquitto
Mosquitto provides the MQTT broker used for real-time multiplayer communication.
MQTT messages are used for information that needs to be shared between connected players quickly, such as:
- Players joining a room
- Players starting movement
- Players stopping movement
- Player positions
- Direction of movement
- Character/sprite information
Using MQTT allows the game clients to communicate with each other through the broker without requiring the clients to communicate directly with one another.
General Architecture
The project separates persistent data from real-time game communication.
┌─────────────────┐
│ GDevelop │
│ Game Client │
└────────┬────────┘
│
┌──────────┴──────────┐
│ │
REST API MQTT
│ │
▼ ▼
┌──────────────┐ ┌──────────────┐
│ JSON Server │ │ Mosquitto │
│ │ │ MQTT Broker │
└──────────────┘ └───────┬──────┘
│
┌─────────┴─────────┐
│ │
Other Clients Other Clients
JSON Server and Mosquitto therefore have different responsibilities:
JSON Server answers the question:
"What is this player's persistent information?"
MQTT answers the question:
"What are the players doing right now?"
Keeping those responsibilities separate allows the game to use a relatively simple database while still providing real-time multiplayer updates.
Local-LAN Design
The current implementation is intended to run on a local network.
The supporting services can be hosted on a local server, while game clients connect to those services through the LAN.
This makes the project useful for experimenting with multiplayer networking without initially requiring cloud hosting or external game servers.
The architecture could potentially be expanded to support Internet-based multiplayer in the future, but that is outside the current scope of the project.
Project Goals
The primary goals of this project are:
- Learn how to implement multiplayer functionality in GDevelop.
- Understand how persistent game data and real-time game data can be handled separately.
- Experiment with MQTT-based multiplayer communication.
- Develop a reusable approach for player registration and authentication.
- Create a room-based multiplayer world.
- Experiment with synchronizing player movement between clients.
- Document the process so the techniques can be reused in future projects.
The project is intentionally being developed incrementally. Features are being added and tested individually rather than attempting to build the entire game architecture at once.
Documentation
This page provides an overview of the project and its architecture.
Detailed implementation information is documented on separate wiki pages. These pages cover individual systems and explain how they are implemented in GDevelop and the supporting services.
Topics include:
- Player registration and authentication
- JSON Server configuration
- Player data structure
- MQTT configuration
- MQTT message formats
- Player movement synchronization
- Room and map management
- Character and sprite management
- GDevelop networking logic
- Deployment and local-LAN configuration
Each system is documented separately so that individual parts of the project can be understood without having to work through the entire game.
Current Status
This project is actively being developed and should be considered a work in progress.
The architecture and implementation may change as new problems are discovered and better solutions are found.
The wiki is intended to document the development process as well as the final implementation. Some of the documentation may therefore describe approaches that were tested, changed, or replaced during development.
Why These Technologies?
This project deliberately uses relatively simple, self-hosted components.
GDevelop provides a visual game-development environment without requiring the entire game to be written from scratch.
JSON Server provides an extremely simple REST-based data store that is easy to inspect and modify during development.
Mosquitto provides a lightweight MQTT broker capable of handling the real-time messaging required for a small multiplayer game.
Together, these technologies provide a simple environment for learning how the different pieces of a multiplayer game fit together without introducing a large dedicated multiplayer framework.
The intent is not necessarily to present this architecture as the best way to build a production MMO. Instead, it is a practical example of how these technologies can be combined to create a small multiplayer game and, more importantly, to learn from the process.
AI Assistance
Portions of this project and its documentation were developed with assistance from OpenAI's ChatGPT. AI assistance was used for brainstorming, troubleshooting, code development, documentation, and exploring potential implementation approaches.
All code and implementation decisions are reviewed, tested, and modified as necessary by the project author.