M6 · Frontier Clash: two sides, one moving front¶
Next major milestone, requested 10 September 2026. Planned, not playable yet.
Fight the Frontier's next mode is a round-based PvP territory battle between two teams, using a reworked version of the existing map. A match should normally last 20–30 minutes. Get equipped quickly, join your side, push the boundary towards the enemy and defend against their counter-push. The current cooperative PvE chapter remains available while this mode is developed.
This takes priority over the broader MMO systems. Banks, long-term equipment progression, repairs, guild economies and the six-frontier MMO remain later work. PvP implementation is a new milestone; adding this plan does not enable PvP in the live campaign.
Proposed first playable rules¶
- Begin with 4 versus 4 development sessions, targeting 8 versus 8 for the first public alpha. These are design and test targets, not measured server limits.
- Two clearly coloured teams start at opposite protected staging areas. Use the existing Greyfen, crossing, quarry, fortress and marsh art, but rebalance routes, travel time and cover for opposing human teams. The old one-way PvE route must not give one side a permanent advantage.
- Connected capture sectors form a readable front. Attack the next adjacent enemy sector or retake a lost one; no jumping directly to the enemy base. The HUD and map show the current contested sector, ownership, capture state and direction of attack.
- The provisional match timer is 25 minutes, with at most two minutes of clearly signalled overtime if a deciding capture is actively contested. Reaching the enemy's final objective wins early; otherwise the team holding more connected territory wins. Equal territory after the final contest is a draw. Confirm scoring and minimum match pacing in playtests.
- Respawn together in short waves at a protected, connected staging point. Prevent spawn camping with protected exits and multiple routes. Cap team imbalance at one where population permits; keep friends together when fair, backfill vacant places and preserve a short reconnect reservation.
- Give both teams equivalent starting gear and the same four weapon families. Use skill, positioning, team roles and limited match-earned upgrades for advantage. No permanent veteran damage advantage and no full loot in this first mode.
- Keep the active gathering/crafting mechanic only where it creates a useful battlefield choice: short local supply jobs for captures or defence, with exact counts and marked sources. Each side must be able to earn its next capture supplies from territory it can currently access. Do not copy PvE recipe locks into a symmetric battle unchanged.
- Friendly fire starts disabled. Server-authoritative team damage, hits, blocks, abilities, respawns, captures and victory are required. Rebalance damage and control effects for human targets instead of assuming PvE numbers transfer unchanged.
- End with a concise result screen showing the team's territory progress and each player's useful contributions, then offer another round. Match territory and temporary resources reset; existing PvE accounts, inventory, quest progress and campaign land do not.
Everything above the fixed two-team / 20–30-minute / reused-map direction is a starting design proposal, to be adjusted through playtesting.
Delivery and acceptance¶
| Stage | Deliverable | Acceptance |
|---|---|---|
| M6.1 · Fair first skirmish | Separate match state, team assignment, damage rules, protected spawns and 4v4 play | Both teams can join, fight, die, respawn and reconnect without damaging PvE saves; controller and keyboard paths both work. |
| M6.2 · A moving battle line | Reworked lanes, adjacent captures, supplies, objective HUD, alerts and counter-pushes | A new player can identify the next objective without the wiki. Both sides can prepare every capture and recover lost ground. |
| M6.3 · A complete round | Warmup, timer, winning condition, overtime, results and reset | Repeated 20–30-minute human rounds, ties, empty teams, joins in progress and reconnects produce the correct result once. No permanent spawn lock. |
| M6.4 · Five versus five simulated players | Ten player-like bots play full opposing rounds through normal player commands | Multiple repeatable seeds, swapped sides and skill profiles. Report winners, duration, objective progress, weapons, deaths, supplies, path failures and server cost. Compare predictions with human matches before calling the mode balanced. |
| M6.5 · Public PvP alpha | An enforced slot cap, abuse controls, hosted operations and tested capacity | Start with an 8v8 target. Run sustained combat, clustered spells/projectiles, join bursts and reconnect tests on the intended host before choosing the actual cap. Complete visible Xbox-controller and mouse/keyboard playtests. |
The current simulation runs at 30 ticks per second. The load gate must measure server tick duration, late ticks, network traffic per player, memory stability and client frame-time spikes during a full round. Test 8, 16, 24 and 32 clients; increase the public cap only when the intended host and real clients retain headroom. Multiple match processes may scale across CPU cores later; extra virtual cores do not automatically speed up one simulation.
M6.4 · Simulate five versus five before tuning by guesswork¶
Build two teams of five simulated players. These are bots controlling ordinary player characters, not privileged NPC combatants. They use the same server-validated movement, aim, equipment, attacks, stamina, cooldowns, blocking, healing, capture, timed gathering/crafting, respawn and team rules as humans. They receive only the information a player could observe; no invisible-enemy tracking, teleporting, infinite resources, invulnerability or skipped objective checks in balance runs.
Each bot needs a limited view, reaction delay, imperfect aim, realistic input rates and a role. Include aggressors, ranged support, defenders and a supply/objective runner. Coordinate when useful, retreat/heal, recover from deaths and choose another route if blocked. Vary accuracy, reactions, weapon mix and team cooperation to represent novice, mixed and practiced groups. The scripts need not call a paid language-model service every frame; reproducible local game AI is the starting approach.
Run whole rounds with fixed random seeds, then swap the teams' spawns and weapon mixes. Include even teams, unequal skill, a disconnected player, low population and a late join. Start with at least 100 paired rounds for each candidate balance configuration where practical. Report sample sizes and uncertainty instead of treating a narrow win rate as proof. Track team wins, round duration, stalemates, comeback rate, capture/defence time, time travelling versus fighting, spawn deaths, weapon damage/kills, ability usage, resource bottlenecks, bot route failures, server tick times and traffic.
Acceptance means the bots can finish valid rounds without privileged shortcuts; side-swapping reveals no unexplained map advantage; all four weapon families have useful roles; supply jobs do not stall rounds; and results can be reproduced. Tune one relevant variable at a time and rerun the same scenarios. Bot mistakes must be distinguished from game imbalance. Simulated balance is evidence for choosing human playtest candidates, not proof of how people will play. Record disagreements with real 5v5 sessions and improve the simulation accordingly.
Current capacity and example running costs¶
Current evidence is a five-client controlled mechanics rehearsal and a two-player public connection/party check. Neither establishes maximum concurrency. The existing service runs one Node simulation and a local SQLite database on the host Mac, through a temporary tunnel. There is no matchmaker or measured public player cap yet. A five-person party limit is not a five-person server limit.
Example always-on VM costs, checked 10 September 2026, in USD, before tax:
| Example host | VM / month | With weekly backups at 20% | Use |
|---|---|---|---|
| 2 shared vCPU, 4 GiB | $24.00 | $28.80 | Low-cost capacity experiment; CPU availability varies. |
| 2 dedicated CPU-optimised vCPU, 4 GiB | $42.00 | $50.40 | Candidate for steadier game ticks; still requires a game-specific load test. |
These examples come from DigitalOcean's published Droplet and backup prices. Allow roughly $30–55/month for this initial VM-and-backup comparison, plus domain costs, taxes, any transfer overage and optional services. It is not a quote for a particular player count, region or complete commercial launch. Hosting hundreds of concurrent players would require measured capacity per match and multiple instances; do not extrapolate directly from this estimate. No paid service has been ordered or enabled by this plan.