OneLiteFeatherNET / OneLiteFeatherNET/Voyager

feat(race): minimum player enforcement, late-join rejection, and DNF handling

Open
#170 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement gameplay
Dominant language
Java
Stars
0
Forks
0
Avg merge
2d 21h
Merged PRs (30d)
12

Description

Description

Race Mode requires a minimum number of players before the countdown can start. Once the map is running, late joiners are rejected or spectated. Players who exceed the time limit without finishing are marked DNF.

Acceptance Criteria

  • Minimum player count is configurable (per-server config, default: 2)
  • Lobby phase blocks countdown start until the minimum is met; displays a waiting message
  • After countdown begins, new connections are either rejected or forced into spectator mode (configurable)
  • A per-map time limit is configurable (default: 150% of reference time)
  • Players who do not finish within the time limit are automatically marked DNF
  • DNF players receive 0 map points and their result is flagged as DNF in persistence
  • DNF is stored as a distinct state from a legitimate 0-point finish (e.g. `ResultType` enum: `FINISH`, `DNF`)
  • The end phase waits for all players to either finish or DNF before advancing
  • Unit tests cover: countdown blocked, countdown unblocked, late-join rejection, DNF timeout

Technical Details

  • `ResultType` enum follows the Enum DSL pattern (cached `VALUES`, `byName()`)
  • Time limit enforcement runs in the game phase tick loop, not a separate thread
  • Spectator behavior for late joiners must not allow ring collision or scoring
  • DB migration adds `result_type` column to `game_results` (non-null, default `FINISH`)

Dependencies

  • #168 (time-bracket scoring — time limit is expressed relative to reference time)
  • #169 (countdown — minimum player check gates the countdown start)

Estimate

M

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the game phase tick loop, the existing ResultType Enum DSL pattern, and persistence for game_results; review dependencies #168 and #169 first. Trace lobby, connection, end-phase, and result flows before checking how configuration and migrations are handled. Done means the listed countdown, late-join, timeout, persistence, and unit-test cases all pass without conflating DNF with a zero-point finish.

Written by the indexing model from the issue text.

Assessment

Tech stack
java
Domain
databases, game-dev
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.