Files
ruby-sea-battle/AGENTS.md
T
2026-11-02 23:44:43 +03:00

29 lines
2.3 KiB
Markdown

# Ruby Sea Battle
## Introduction
"Ruby Sea Battle" is a battleship-like **multiplayer browser game** with a simple React front-end and a back-end composed of two servers:
- **the main server** for handling users (sign-up/sign-in, profile customization, etc.), direct user-to-user interactions, match-making and player rating.
- **the game server** for managing matches, with real-time client-server communication and score calculation. The players are invited to join the game on the game server by the main server, and once the game finishes the game server reports back the results.
## Tech stack
- **Ruby on Rails** is used as a basis for the main server, implementing only an HTTP API without hosting the front-end.
- The game server is written in Go with no framework, implementing a WebSockets server
## Directory structure
The repository's directory structure is simple: there are 3 directories for each part of the project: `frontend`, `game-server` and `main-server`. The documentation for `main-server` currently resides fully in `main-server/API.md`, but more files can be added in `main-server/docs`, if needed. `game-server` also has its own `README.md`, where all relevant information is contained at the moment. The docs for `main-server` and `game-server` are in Russian.
## Project roadmap
- [x] Basic sign-up/sign-in function
- [x] Matchmaking with delegation to the game server (using a shared JWT secret)
- [x] Actual game logic & game UI
- [x] Ship placement UI and logic
- [x] Battle UI and logic
- [x] End of battle UI
- [ ] Saving results on the main server, match history, rating calculation
- [ ] Additional in-game features: chat, reactions, live connection status
- [ ] Profile customization
## Guidelines
- The mentioned documentation files should be kept up-to-date and updated in the same language. The formatting can be changed, though, if it could improve readability.
- The Ruby backend should be written with Rails principles in mind. The tasks performed by this backend are going to be relatively simple (especially at earlier stages of this project), so the focus should be on clean code and best practices, not unnecessary complexity.
- The methods in the Ruby backend comprising the business-logic should be covered with unit-tests after being implemented.