**This PR improves spawn highlighting to identify self and friend/foe.
Suggested Label: Feature
Suggested Milestone: v26 or v27**
## Description:
**This PR changes the behavior for spawn color highlighting and
addresses issue #2270.**
Currently, the user's spawn highlight color is the same as all other
players in FFA and the same as all enemies in Team games. Although
"breathing" rings were added recently for the user's spawn highlight,
this can still be difficult to find on the map, especially with large
player counts.
This PR modifies how spawn highlights are drawn for the user and for
allies and enemies in Team games.
### User Spawn Color Updates
First, an additional spawn highlight color was added for the user in
`src/core/configuration/PastelTheme.ts`: `_spawnHighlightSelfColor`.
This is defined to be white (0xFFFFFF).
Second, the breathing ring was modified to improve visibility (all in
`src/client/graphics/layers/TerritoryLayer.ts`) :
- A radial-gradient transparent ring in the spawn color (white) is drawn
at all times
- The ring is transparent for `radius = 8` pixels from the player's
center point
- The gradient extends from `8` to `24` pixels from the player's center
point
- The first 10% of the ring (~ 1 pixel) is solid
- The remaining ring fades to transparent at `24` pixels
- A solid, "breathing" ring is drawn on top of the transparent ring
- The solid ring is also transparent for `radius = 8` pixels from the
center point
- The outer radius of the solid ring is a function of "time" in the same
way that the current breathing ring is implemented.
- The solid ring therefore grows and shrinks to cover the transparent
ring
### Other Player Spawn Color Updates
In FFA games, no change is made to the spawn color highlight of other
players. It remains `rgb(255,213,79)`.
In team games, the spawn color highlight of other players is updated to
use their team colors. For example, a player on the red team will have a
red spawn highlight, while a player on the purple team will have a
purple spawn highlight.
Both of these changes are handled with a simple update in
`src/client/graphics/layers/TerritoryLayer.ts` within the
`spawnHighlight()` method:
```typescript
const myPlayer = this.game.myPlayer();
if (myPlayer !== null && myPlayer !== human && myPlayer.team() === null) {
// In FFA games (when team === null), use default yellow spawn highlight color
color = this.theme.spawnHighlightColor();
} else if (myPlayer !== null && myPlayer !== human) {
// In Team games, the spawn highlight color becomes that player's team color
// Optionally, this could be broken down to teammate or enemy and simplified to green and red, respectively
const team = human.team();
if (team !== null) color = this.theme.teamColor(team);
}
```
### Attached Images
Three images have been attached. The three images show a progression of
the "breathing" user highlight. They also show the team-specific
highlights of players on other teams. (Note that Nations in the private
game were assigned teams but do not have spawn highlights).
<img width="1161" height="895" alt="Screenshot 2025-10-22 211929"
src="https://github.com/user-attachments/assets/71d466b8-61e4-4e30-83e5-06efdfc706ce"
/>
<img width="1322" height="934" alt="Screenshot 2025-10-22 212003"
src="https://github.com/user-attachments/assets/4e6c18b7-7f9e-436d-afb9-85a08a11c40b"
/>
<img width="1340" height="954" alt="Screenshot 2025-10-22 212028"
src="https://github.com/user-attachments/assets/597d0ed5-5519-4cf7-bc60-9963da3f7d7f"
/>
### Misc.
- I added `.idea/` to `.gitignore` because I use JetBrains IDEs
- I expanded the `fallbackColors` list. Right now it has a lot of green
colors, so I added equivalents for red, blue, cyan, magenta, and yellow.
## Please complete the following:
- [x] I have added screenshots for all UI updates
- [x] I process any text displayed to the user through translateText()
and I've added it to the en.json file
- [x] I have added relevant tests to the test directory
- [x] I confirm I have thoroughly tested these changes and take full
responsibility for any bugs introduced
## Please put your Discord username so you can be contacted if a bug or
regression is found:
GlacialDrift
OpenFront.io is an online real-time strategy game focused on territorial control and alliance building. Players compete to expand their territory, build structures, and form strategic alliances in various maps based on real-world geography.
This is a fork/rewrite of WarFront.io. Credit to https://github.com/WarFrontIO.
License
OpenFront source code is licensed under the GNU Affero General Public License v3.0 with additional attribution requirements:
- Any forks or derivative works must display attribution (e.g., "Based on OpenFront", "Derived from OpenFront", "Powered by OpenFront", or "Fork of OpenFront") prominently on the main menu and/or initial title screen.
See the ADDITIONAL TERMS section in LICENSE for complete requirements.
For asset licensing, see LICENSE-ASSETS.
For license history, see LICENSING.md.
🌟 Features
- Real-time Strategy Gameplay: Expand your territory and engage in strategic battles
- Alliance System: Form alliances with other players for mutual defense
- Multiple Maps: Play across various geographical regions including Europe, Asia, Africa, and more
- Resource Management: Balance your expansion with defensive capabilities
- Cross-platform: Play in any modern web browser
📋 Prerequisites
- npm (v10.9.2 or higher)
- A modern web browser (Chrome, Firefox, Edge, etc.)
🚀 Installation
-
Clone the repository
git clone https://github.com/openfrontio/OpenFrontIO.git cd OpenFrontIO -
Install dependencies
npm i
🎮 Running the Game
Development Mode
Run both the client and server in development mode with live reloading:
npm run dev
This will:
- Start the webpack dev server for the client
- Launch the game server with development settings
- Open the game in your default browser
Client Only
To run just the client with hot reloading:
npm run start:client
Server Only
To run just the server with development settings:
npm run start:server-dev
Connecting to staging or production backends
Sometimes it's useful to connect to production servers when replaying a game, testing user profiles, purchases, or login flow.
To connect to staging api servers:
npm run dev:staging
To connect to production api servers:
npm run dev:prod
🛠️ Development Tools
-
Format code:
npm run format -
Lint code:
npm run lint -
Lint and fix code:
npm run lint:fix -
Testing
npm test
🏗️ Project Structure
/src/client- Frontend game client/src/core- Shared game logic/src/server- Backend game server/resources- Static assets (images, maps, etc.)
🤝 Contributing
Contributions are welcome! Please feel free to submit a Pull Request.
- Request to join the development Discord.
- Fork the repository
- Create your feature branch (
git checkout -b amazing-feature) - Commit your changes (
git commit -m 'Add some amazing feature') - Push to the branch (
git push origin amazing-feature) - Open a Pull Request
🌐 Translation
Translators are welcome! Please feel free to help translate into your language. How to help?
- Join the translation Discord
- Go to the project's Crowdin translation page: https://crowdin.com/project/openfront-mls
- Login if you already have an account / Sign up if you don't have one
- Join the project
- Select the language you want to translate in. If your language isn't on the list, click the "Request New Language" button and enter the language you want added there.
- Translate the strings
Feel free to ask questions in the translation Discord server!
Project Governance
- The project maintainer (evan) has final authority on all code changes and design decisions
- All pull requests require maintainer approval before merging
- The maintainer reserves the right to reject contributions that don't align with the project's vision or quality standards
Contribution Path for New Contributors
To ensure code quality and project stability, we use a progressive contribution system:
-
New Contributors: Limited to UI improvements and small bug fixes only
- This helps you become familiar with the codebase
- UI changes are easier to review and less likely to break core functionality
- Small, focused PRs have a higher chance of being accepted
-
Established Contributors: After several successful PRs and demonstrating understanding of the codebase, you may work on more complex features
-
Core Contributors: Only those with extensive experience with the project may modify critical game systems
How to Contribute Successfully
-
Before Starting Work:
- Open an issue describing what you want to contribute
- Wait for maintainer feedback before investing significant time
- Small improvements can proceed directly to PR stage
-
Code Quality Requirements:
- All code must be well-commented and follow existing style patterns
- New features should not break existing functionality
- Code should be thoroughly tested before submission
- All code changes in src/core MUST be tested.
-
Pull Request Process:
- Keep PRs focused on a single feature or bug fix
- Include screenshots for UI changes
- Describe what testing you've performed
- Be responsive to feedback and requested changes
-
Testing Requirements:
- Verify your changes work as expected
- Test on multiple systems/browsers if applicable
- Document your testing process in the PR
Communication
- Be respectful and constructive in all project interactions
- Questions are welcome, but please search existing issues first
- For major changes, discuss in an issue before starting work
Final Notes
Remember that maintaining this project requires significant effort. The maintainer appreciates your contributions but must prioritize long-term project health and stability. Not all contributions will be accepted, and that's okay.
Thank you for helping make OpenFront better!