Advice Request: Variable Unit Cost

[toddp]

I have a new AB 3.1 project that is stretching my abilities as an author. I think AB 3.1 has all of the features I require, but could use some advice as to the structure of the data files.

The system starts with a deck of cards. Each card has a weight and a special ability. Those of you familiar with Piquet may understand the system. The sum of the weights and the total of the cards is limited.

The totals of the different cards will then modify the cost of the army basic units.

The basic army units then include the armor, weapons, and skills for the various fighting units.

AB3.1 has the various features required to calculate the cost of the various units and it has the facilities to modify the equipment and items. I am having trouble with the first step. How to model the creation of the deck of cards?

I considered adding a mandatory item as in the example file for the Magistrate Enforcers. Is there a way to disable the delete of the item? I could then use this item to calculate the basic army costs and let the user add the unit entities to the list based on these costs.

Flow to create the army:

A. Create the card deck
B. Validate the card deck
C. Calculate the basic unit costs from the card groups
D. Add units from the basic costs and provide equipment and armor
E. Calculate army costs


comments welcome.

Regards,

Todd

 

[Russell]

I've had a read of this a couple of times and I'm still not sure how this is supposed to work. Can you give a simple example with real card / unit names etc. to better explain?

Russell.

 

[toddp]

sure.

First the user selects a set of cards that define the army:

2 Infantry Move, 2 Melee, 2 Cavalry Move, 1 Difficult Terrain, 10 Milling About, 1 Uncontrolled Charge

Total of 18 cards.

The Infantry and Cavalry move cards increase the infantry and cavalry unit costs by 4%
The Melee cards increase the army costs by 4%
The uncontrolled charge reduces the army costs by 2%.

Lets assume the basic infantry unit is 10 points and a cavalry unit is 20 points.

Further let's say that the user selects armor and weapon costs for an additional +10% for the cavalry and infantry units.


The costs for the infantry unit is now 10 + (4%+4%-2%+10%) or 10 * 1.16 or 12 points
The cavalry is then 20 + (4%+4%-2%+10%) or 20 * 1.16 or 23 points.

 

[rob]

This is helpful, but there are still some important details missing here. Is there a cumulative percentage cost for EACH card or does the mere presence of a card impart the adjustment? In other words, is the 4% for move cards in your example derive 2% per move card or 4% for having any move cards?

Also, is there a fixed number of cards that must be chosen? Or can it vary? If variable, what are the parameters associated with deck construction?

Those questions not withstanding, I would set this up with an automatically added item in the way you proposed. There is no way to keep the user from deleting an item, but you can easily write a validation rule that confirms the item is present in the roster. I would then either implement the various cards as options or child items on the "Deck" item. Options might seem best at first glance, but child items would allow you to show each of them with their impact as children of the Deck in the roster. The summary text for each child item would be very informational to the user as he designs the army. You could either have the user modify the option via a range behavior to specify the count or manipulate the child items directly. I think the former would be more usable, but the latter would show the count always within the child items for quick reference. You'll need to make this call based on your knowledge of how army construction works for the game.

The trick for applying the cost adjustments is to use global tags. Since all the global tags will be managed via the one Deck and changes to the Deck must trigger a recalculate of everything, using global tags in this case is a good solution (many times they aren't). If you use options only, you'll need to assign the appropriate number of tags via Evaluate scripts on each option. If you use child items, you can use "auto-tags" on each of the items to properly assign all the global tags.

To apply the cost adjustments, you'll need to write scripts that tally the applicable percentage adjustment for a given units and then apply that adjustment. The best approach here is probably to have a private unit stat that tracks the percentage for each unit. You can then have separate options for each card that contain Live tag expressions to test for the proper tag and then adjust the percentage by the proper amount based on the number of tags of the type (obtained by using "tagcount" within the Evaluate script). All of the options can then be lumped into a single linkset, and then that one linkset can be attached to all units. This makes it trivial to add support for new cards or units in the future.

The last thing you'll need is to define a global EntityDone script that multiplies the final unit cost by the value given by the percentage unit stat. Since the options will calculate the proper net adjustment for each unit within the percentage unit stat, the value of that stat can then always be applied to the unit to yield the final value.

The above approach ought to be pretty quick and simple to implement. The questions at the top will substantively impact the way the Deck item is handled, as well as how the percentage adjustment is calculated. Otherwise, the approach should work smoothly.

Hope this helps,
Rob

At 11:19 AM 1/4/2006, you wrote:

sure.

First the user selects a set of cards that define the army:

2 Infantry Move, 2 Melee, 2 Cavalry Move, 1 Difficult Terrain, 10 Milling About, 1 Uncontrolled Charge

Total of 18 cards.

The Infantry and Cavalry move cards increase the infantry and cavalry unit costs by 4%
The Melee cards increase the army costs by 4%
The uncontrolled charge reduces the army costs by 2%.

Lets assume the basic infantry unit is 10 points and a cavalry unit is 20 points.

Further let's say that the user selects armor and weapon costs for an additional +10% for the cavalry and infantry units.


The costs for the infantry unit is now 10 + (4%+4%-2%+10%) or 10 * 1.16 or 12 points
The cavalry is then 20 + (4%+4%-2%+10%) or 20 * 1.16 or 23 points.

 

[toddp]

Excellent reply. Thank you. I've implemented many of the suggestions already using global stats associated with the card deck.

In answer to your question regarding deck construction, it is complicated.

There is an overall limit on the number of cards 26 - 29. Each card is assigned a weight, more valueable cards weigh more and there is a limit on total weight. This should be a fun validation rule to accomplish, but I'm not there just yet.

The unit costs adjustments are non-linear. One move card would be 2%, two would be 4%, 3 would be 10%. Each card will have an associated eval script to accumulate its impact on the sub units.

I don't think this would have been possible to write in AB2. It is taking me a bit to correctly specify the various relationships and I have reorganized the file several times. The complexity of the language is slowing me down as I learn about the various constructs. You know, need to do this, look it up, try to understand it, implement, test, implement... I find it entertaining to solve the UI problems with the language.

Regards,

Todd