Let me explain...
In ADOM Classic building things always is a special case. ADOM II in contrast got the notion of construction plans to build things when I introduced tinkers. A construction plan in Java roughly is defined like this:
public interface ConstructionPlan
boolean isKnownBy(Being being);
boolean isExecutableBy(Being being, Position targetPosition);
boolean executeBy(Being being, Position targetPosition, int sequenceNumber);
int getActionsRequiredToBuildOneYield(Being being);
So a construction plan can
- determine if it is known by an arbitrary being,
- if the being could execute the actual construction work,
- describe the yield of the construction work (is the terminology correct?),
- actually be executed,
- describe its requirements and
- tell you how long it takes to execute the construction plan (counted in actions).
For fletchery in my first implementation attempt I fell back into bad ADOM Classic habits and implemented a special case. Then I remembered construction plans as the seemingly better abstraction and that's where it gets complicated:
- In ADOM Classic items are pretty simple things and all item types are very different (e.g. mithril arrows and sternum arrows are totally different item types).
- This is different in ADOM II: There is only one item type for arrows (actually there are hunting arrows, sheaf arrows and war arrows but the details don't matter) and each such item has a main material (e.g. mithril or iron).
- In ADOM Classic most missiles were supposedly wood.
- Since we have more detail in ADOM II it probably would make sense to allow building different missile types with fletchery (e.g. mithril hunting arrows or eternium war arrows).
- If I were to use construction plans for that I'd either have to define different plans for each type of arrow in combination with the material (which is not really a problem but could become pretty hard to keep under control for the player if you know a lot of construction plans) or I'd have to make construction plans more flexible to allow for variant requirements (e.g. to build an arrow you need a wooden shaft and some metal tip - and then the plan would have to derive the specific yield from the chosen variant materials).
- As construction plans are totally generic and requirements basically are complex Boolean expressions this seems to be difficult... or I am missing something.
So I really need to think about whether I either need to throw away the whole current implementation or patch it somehow... just for that damn fletchery skill as arrows are the first thing to build where you want to build larger quantities with one command and need material resources dependent on the number of things produced. Oh well... I guess, I'm having to change the whole implementation.
The result will be a much more flexible construction system for future ideas but I really had hoped to avoid such large changes in that area.
The life of a programmer... and then people wonder why it's costly to change things in 150.000+ lines of mostly undocumented legacy code... the irony.
P.S.: Yes, I know that this post was probably totally incomprehensible mumble-jumble for non-programmers. Nonetheless I need to talk about this ;-)