Advice on variable unit cost

[toddp]

I'm working with a game system with variable unit costs. There are two distinct ways to create an army:

1. create a card deck, which modifies the basic values of the units
2. use an existing army list, then every unit has set basic costs based on the quality of the unit

Both methods 1 and 2 are then modified based on the weapon and armor assigned.

I have received a lot of great advice on the forum on how to solve problem 1. I used global tags for the card deck and then pass this information to the various units. The costs are calculated and everything works great. I have defined tag groups like:

infcost.mil25
infcost.eli40
...

to track the starting costs of the infantry, cavalry, warmachine, monsters, and characters. These tag groups are used in association with the global tags defined by the card deck. The units -- infantry, cavalry, etc. -- then call procedures combining the starting costs using the quality option selected, the weapons, and calculate the value for each unit.

I am now moving on to the other armies in the system. This is method 2. Each army has specific advantages and disadvantages. The card deck is fixed and does not modify the cost of the units.

I see several methods for implementing the variable costs. I would like the opinions from the group based on your experience.

A. redefine the units for each list. copy the linksets. copy the unit menus. add the specific options based on the army. add taggroups for each nation, each unit type, keeping the size of each tag group small but adding quite a few tag groups.

B. reuse the existing units. Add the costs for each unit type and each nation to the existing groups. Use the override feature on the units to strip out the unwanted tags. Change the scripts to ignore the carddeck information. most of the existing scripts can then be reused.

Option A has the advantage that each unit is unique and complete, but I would have to duplicate a lot of script, linkset, and option information between the nations. Option B reduces the duplication but then the linkset for each unit could get messy with the number of options active only based on specific roster tags.

I think option B will be the most maintainable in the long run, but am open for suggestions.

Rest regards,

Todd

[rob]

As you point out, an argument can be made that Option B is more maintainable due to the reduced duplication. However, that might not truly be the case. Reducing duplication absolutely speeds up the implementation process, but having lots of confusing tag expressions to control when/how various components do/don't apply can impact maintainability in a significant way. I've definitely seen situations where the data files become messy and hard to maintain in an effort to re-use. So an argument can also be made that creating lots of independent, self-contained data files simplifies maintenance. It's a VERY grey area, and it really depends on the level of complexity that will be introduced to achieve re-use and avoid the duplication.

I realize that doesn't help as much as you'd like, because it doesn't give you a concrete A vs. B recommendation. However, it's really a tradeoff, and only you know how much weight to give each side of the argument. So I'll keep my fingers crossed is does prove useful. :-)

Here's an additional few tricks and pieces of advice you can use, depending on whether you go with Option A or B. These might help to skew the tradeoff in favor of one direction or the other. I'm basing these on your brief comments below, so I'm working with minimal information. In other words, consider these options, but do NOT take them as gospel. If they don't seem appropriate, either ask more questions or ignore them. :-)

1. Having lots of links within linksets, with many of them having Live tagexprs, can be a really nuisance to maintain. It's MUCH easy than not having the linksets, but there might be a simpler way to keep things manageable. The trick is to use chained links. You can have one option chain to lots of other options. This makes it possible to establish one "root" option for race X, another for race Y, etc. The root option for race X chains to all of the options that are available for race X, and the root option for race Y chains to the proper options. You can then have your linkset consists of the various root options. Each of the root options can have the proper Live tagexpr for the race, and then all of the other options don't have to worry about the restrictions. They will automatically be governed by the root option.

2. It sounds like you have lots of races that use the card decks and lots of races that don't. If you test on the race tags to determine whether to apply behaviors for the card deck or not, the tagexprs could get messy. But you can greatly simplify things by using shared race tags. When you define a race, a "race" tag is automatically defined for the that race. However, you can also define your own tags and have then assigned whenever the race is selected. For example, you could have one tag to indicate the use of card decks. You could then assign that tag as an additional auto-tag for each race that utilizes card decks. That one tag would then be defined whenever any of those races were in use. If a different race were used, that tag would not exist. You could then write very simple tests to determine whether to apply card deck behaviors, since you'd only need to check against that one tag.

3. Remember that you rarely need to duplicate options. You can have different units from different races all share the exact same options. They would simply have their own links to those options, and you can override just about anything you want via the link. So assigning an option a different price for one race vs. another, or a different name, or whatever, is very quick and easy via the link.

4. I don't know how you have things setup, but adding new tag groups for each nation may not be necessary. You could easily re-use the same tag groups across various races. Also, remember that you can use wildcards in tagexprs, so you can have different tags with a shared "base" portion that can be tested separately or together via wildcards. Using wildcards adds a lot of flexibility and opportunity for re-use, but it can also force you to use a different organizational structure than "race-based" for tags.

5. If you need to add lots of tag groups, there really isn't any meaningful "cost" associated with doing so. Feel free to add a hundred different tag groups if your design requires it. However, please check with us first if you have a large number of tag groups, since there might be a better way to model things that you just haven't thought of yet. :-)

6. The override mechanism within AB was designed with the assumption that there would be a nominal number of overrides for each unit. If you find that you'll have more than a dozen different overrides on multiple units, please let us know. It might be that you've got a unique situation that we didn't anticipate, in which case we need to learn more about what you're doing to figure out how best to handle things.

7. If you find yourself needing to duplicate scripts, see if there's a way to leverage procedures. In general, there should NOT be a need to duplicate a lot of scripts across races.

Hope this helps,
Rob


At 08:31 AM 2/26/2006, you wrote:

A. redefine the units for each list. copy the linksets. copy the unit menus. add the specific options based on the army. add taggroups for each nation, each unit type, keeping the size of each tag group small but adding quite a few tag groups.

B. reuse the existing units. Add the costs for each unit type and each nation to the existing groups. Use the override feature on the units to strip out the unwanted tags. Change the scripts to ignore the carddeck information. most of the existing scripts can then be reused.

Option A has the advantage that each unit is unique and complete, but I would have to duplicate a lot of script, linkset, and option information between the nations. Option B reduces the duplication but then the linkset for each unit could get messy with the number of options active only based on specific roster tags.

I think option B will be the most maintainable in the long run, but am open for suggestions.

[toddp]

Great advice as always, Rob.

Best regards,

Todd