beyond-all-reason / beyond-all-reason/RecoilEngine
Consider thinking about startposition API as opposed to default engine handling
- Dominant language
- C++
- Stars
- 679
- Forks
- 290
- Avg merge
- 3d 2h
- Merged PRs (30d)
- 40
Description
Currently the only way the engine allows games that have manual start pos configured at pregame for start positions to be set is via mousepress, hardcoded by the engine in [StartPosSelecter](https://github.com/beyond-all-reason/RecoilEngine/blob/a9bd9de5ccd59cc28c13105f2d3c1249ae3c4f63/rts/Game/UI/StartPosSelecter.cpp).
This creates a few problems:
- The player is strictly required to click on a map position for the game to set the startpos at that location (games can't implement their own logic to set startpos as there is no setter in the API)
- Games that accept above, still have to workaround all clicks setting pos when interacting with the game gui by manually detecting that the mousepress is not above any particular gui component (or whatever specific logic) and halting the chain (return of the callin), the behavior is implicit instead of explicit and hard to reason about, bug prone.
- Engine has to maintain hardcoded logic that has its place for simplicity, but can (should?) be offloaded to games
Proposal is to consider API changes to enable games setting startpos, a setting for games to be able to ignore the engine handling and an example widget (setstartpos with output of tracescreenray on mousepress)
See also:
- https://github.com/beyond-all-reason/RecoilEngine/blob/a9bd9de5ccd59cc28c13105f2d3c1249ae3c4f63/rts/Net/NetCommands.cpp#L525
- https://github.com/beyond-all-reason/RecoilEngine/blob/a9bd9de5ccd59cc28c13105f2d3c1249ae3c4f63/rts/Game/UI/StartPosSelecter.cpp
Contributor guide
Research direction
Start by reading rts/Game/UI/StartPosSelecter.cpp and the related handling in rts/Net/NetCommands.cpp around line 525. Trace how mouse presses currently set manual start positions, then define the API and configuration behavior needed for game-controlled placement and engine opt-out. Done means the proposed API behavior is specified, implemented, and covered by an example setstartpos widget using tracescreenray output.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- api, game-dev
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100