APuddle210 40befee080 Optimize terrain map gen perf (#334)
### Summary
Investigated and resolved slow execution time of this script since the
addition of the thumbnail generation functionality. Determined that
thumbnail generation was not the source of the increased execution time,
likely due instead to change from bun back to npm. Some other minor
improvements made.

### Execution Time Optimizations
Investigated which components of the process were taking the most time
and determined the longest running component to be the
`removeSmallLakes()` function. Research determined that the `.forEach`
looping method to be significantly slower than the `for (const var of
vars)` method and replaced all instances of the former with the latter.

Further review identified possibility to reduce the number of calls to
the getArea() function by combining the `removeSmallLakes()` with the
`processOcean()` function, which was already determining the size of all
bodies of water.

After revision to the `forEach` loops and inclusion of
`removeSmallLakes()` within `processOcean()`, the next slowest executing
component was the `processDistToLand()` function. Aside from being slow
this function was also difficult to understand. Revised function perform
Manhattan distance calculations against the `shorelineWaters[]` array
and identify the minimum value rather than walking out from the
shoreline using the `neighbors()`. This change yielded between ~35% -
~45% faster execution times for this function (~275 seconds -> ~150
seconds; ~225 seconds -> ~165 seconds).

The change to `processDistToLand()` was tested by running the new
version of the function alongside the old version of the function and
having any differences in the calculated distance to land printed to the
console. Initially the test identified errors arising from a reference
to an x coordinate value that should have been a y coordinate value.
Once resolved no further differences were found.  

### Other Minor Changes
Changes to `processOcean()` now also explicitly prevent the largest body
of water from being removed, regardless of what value is passed in for
`removeSmall`, and additionally nest the calls to `processShore()` and
`processDistToLand()` within this function rather than within
`generateMap()` for better comprehensibility. `processOcean()` renamed
to `processWater`.

Also inserted additional console.log lines to better communicate state
of the scripts during runtime, removed unnecessary export statement from
`createMiniMap()` function which requires parameters not readily
available from outside contexts (and which was not called externally
anyways). Revised multiple instances where `terrain` was used to refer
to a single item of a Terrain[][] array to instead use `tile` for
comprehensibility, and consistency with the terminology used elsewhere
in the application.

Added an explicit variable declaration of `removeSmall` to the
generateTerrainMaps.ts file and included it in the call to
`generateMap()` to make toggling this option easier in the future. Moved
the `min_lake_size` constant out of the relevant function and to the top
of the TerrainMapGenerator.ts file for better visibility and consistency
with where `min_island_size` is being declared.
2025-03-24 20:32:51 -07:00
2025-03-17 16:52:32 -07:00
2025-03-06 15:50:29 -08:00
2025-03-24 20:32:51 -07:00
2025-03-07 16:37:39 +00:00
2025-03-05 08:04:12 -08:00
2025-03-06 15:50:29 -08:00
2025-02-18 17:23:37 -08:00
2025-03-07 16:51:15 +00:00
2025-03-06 20:52:40 -08:00
2025-02-14 14:03:22 -05:00
2025-02-12 08:38:56 -08:00
2025-03-22 17:01:51 -07:00
2025-02-20 00:48:45 +02:00
2025-03-22 13:26:47 -07:00

OpenFrontIO

OpenFrontIO Logo

Prettier Check

OpenFront 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.

🌟 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

  1. Clone the repository

    git clone https://github.com/openfrontio/OpenFrontIO.git
    cd OpenFrontIO
    
  2. 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

🛠️ Development Tools

  • Format code:

    npm run format
    
  • Lint code:

    npm run lint
    
  • Lint and fix code:

    npm run lint:fix
    

🏗️ Project Structure

  • /src/client - Frontend game client
  • /src/core - Shared game logic
  • /src/server - Backend game server
  • /resources - Static assets (images, maps, etc.)

📝 License

This project is licensed under the terms found in the LICENSE file.

🤝 Contributing

Contributions are welcome! Please feel free to submit a Pull Request.

  1. Fork the repository
  2. Create your feature branch (git checkout -b amazing-feature)
  3. Commit your changes (git commit -m 'Add some amazing feature')
  4. Push to the branch (git push origin amazing-feature)
  5. Open a Pull Request

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:

  1. 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
  2. Established Contributors: After several successful PRs and demonstrating understanding of the codebase, you may work on more complex features

  3. Core Contributors: Only those with extensive experience with the project may modify critical game systems

How to Contribute Successfully

  1. 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
  2. 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.
  3. 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
  4. 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!

S
Description
Languages
TypeScript 91.3%
GLSL 2.6%
JavaScript 1.9%
HTML 1.7%
CSS 1%
Other 1.5%