The problem with that, though (aside from suspension of disbelief) is computing cost. Every custom transition would also have a custom cost associated with it (the difference between unit type x and unit type y, plus probably some gildar to cover "retraining").
um, no ?
This is a simple one-time cost.Which a player will, at most, do once every few minutes. or maybe 50 times simultaneously in a bulk operation
The process for doing it is thus:
1. Make a list of all equipment the unit currently has (possibly traits too)
2. Make a list of all equipment the newly upgraded unit will have (possibly traits too)
3. Remove from both lists, any items which are in both (ie, any of the new items which the unit already has before upgrading)
4. Total up the labor, metal, crystal and resource costs of each item in the new list
5. charge that to the player's account, and/or present some kind of dialog showing them the cost
the whole operation is pretty simple and the biggest time cost would probably be in swapping out the unit graphics, which is a cost that already exists with upgrading anyway. Any computer in the world is going to be able to do those first 5 steps in less than 0.1 seconds, and that's a conservative estimate. computationally, it's nothing.
The only time CPU costs really enter the equation is in two major situations:
A: Large operations. Things on a big scale, like the code that handles movement or updating every unit on the map. It has a big data set to work with, but is used very infrequently (the average turn is between a few seconds, to several minutes. That's infrequent in computing terms)
B: High frequency operations. Things which are run regularly. From a computing perspective, regular means several times per second
For things that don't fit in either of these categories, a developer can, by and large, not bother optimising. Or even deliberately slow the operation down, and nobody will ever notice any difference.
