beyond-all-reason / beyond-all-reason/RecoilEngine
[FR] Make resources fungible
- Dominant language
- C++
- Stars
- 679
- Forks
- 290
- Avg merge
- 3d 2h
- Merged PRs (30d)
- 40
Description
Ideally a game would be able to swap the two resources and see no behaviour difference. Currently metal and energy each behave slightly differently.
The following are hardcoded:
* only energy can be used as a cost for repair, resurrect, capture, and reclaim.
* only metal value is used as scaling when feature reclaim has a cost.
* only metal can be extracted (as in mexes interacting with the metalmap).
* only energy can be used as upkeep for abilities such as cloaking, jamming, shields, metal extraction and metal making.
* only metal can be used as a filter for the CTRL modifier for reclaim.
* when Lua is involved and both resources produce an event, metal is usually ran first. Ideally there would be a single event with two parameters.
And there's further differences in defaults (so these can be overridden by a game, if the game is aware of them):
* built-in tree features default to 250 energy but 0 metal.
* unit mass defaults to metal.
* feature mass defaults to some function of resources, but counts metal as worth 4 energy.
* unit "power" defaults to some function of resources, but counts metal as worth 60 energy.
* the "harvestStorage" tag acts as a fallback for metal harvest storage but not energy harvest storage.
* default metal share level ("red slider") is set to 99% for metal but 95% for energy.
* unless gadgeted, factory cancel and construction decay return 100% metal and no energy.
* unless gadgeted, unit reclaim returns only metal.
* unless gadgeted, wind and tidal produce energy only.
When both resources are involved, metal is usually processed first. This is often fine since one of them has to be, though ordering quirks like "can use self-produced metal to pay for own metal upkeep, but not energy" would ideally not exist if feasible.
Contributor guide
Research direction
No files, tests, or entry points are named. Begin by mapping each listed metal- and energy-specific behavior to the engine subsystems that implement it, then establish which resource-swapping behaviors must become equivalent and how parity will be tested.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- game-dev
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100