Forge version 1.3.1

[RumbleBBU]

The prices are also unchanged

Actually, that's slightly different from my yesterday's commit, isn't it? http://svn.slightlymagic.net/websvn/lis ... &peg=18161

Yes, I did change the minimum price from 10000 to 7500 but I also changed the straight 50x modifier to a formula that uses pow and sqrt. The reason for this was that the price differences between the editions were too steep when multiplied.

The old formula gives higher prices for all sets, and a ludicurously high price for Unlimited (let alone Alpha or Beta). My original reasoning was that since I had added a button that let you unlock almost anytime, I had to jack up the prices to limit it somehow.

Then I realized that the prices were so high that no-one would play a single quest long enough to unlock more than just a set or two, and no more, ever...

[Max mtg]

ok, would you correct the formula in place?

[RumbleBBU]

Done.

Just a brief query, how is the selection of available sets formed currently?

The old version gave you just a limited selection of "nearby" choices (initially 2, more when you had more wins, up to eight). That is, if you were playing with modern sets, you couldn't all of a sudden jump and unlock Unlimited - or vice versa. You had to slowly build your way there.

In the current code, (with my old quest saves), it seems that I get the list of all sets to choose from. The nearby sets are on the top of the list, though.

[RumbleBBU]

Answering my own question...

The unlock tokens...they are currently used to determine how many sets you can unlock, which is fine. However...

Code: Select all

final int nrChoices = qData.getUnlocksTokens();

In the original version, the nrChoices variable was used to determine the number of different choices that were displayed for you to choose from. The current implementation does not use this value at all (except for a test that could have been just as easily made against getUnlockTokens()) and instead simply displays a list of all (currently 'locked') sets.

I would suggest that instead of using unlock tokens here, just use a more static value, for example 2 + wins/50 (max 8 ), and then display that many sets to choose from.

(Is there a neater way to do that than to form a new List and then get() elements 0...(nrChoices-1) from the full list into it with a for loop?)

[moomarc]

I would suggest that instead of using unlock tokens here, just use a more static value, for example 2 + wins/50 (max 8 ), and then display that many sets to choose from.

Maybe have the max and divisor as a user adjustable preferences (with a note for the less math-savvy noting that a lower divisor will yield a higher number of choices). Then users that want to be able to unlock any set can do so, while more hardcore players can make life difficult for themselves

[RumbleBBU]

Maybe have the max and divisor as a user adjustable preferences (with a note for the less math-savvy noting that a lower divisor will yield a higher number of choices). Then users that want to be able to unlock any set can do so, while more hardcore players can make life difficult for themselves

In the future, yes.

Although the dialog will not look as pretty if you have to scroll the list (i.e., after more than 8 choices).

But that'll take a bit more code, especially if we want to have different values for the different difficulty settings. (Maybe the unlocking price multiplier could also be different per difficulty setting.) In 1.3.2, I'd say, if we are aiming to get 1.3.1 out today or on Monday.

As a quick 'fix', I've now committed a piece of code that restores the earlier behavior. Max, please feel free to modify it if you don't like it or if you know a better way to achieve the same result than the new List + for loop method I used.

[Max mtg]

at r18194:

to take first N items:

Code: Select all

options.subList(0, nrChoices)

ensure that nrOptions <= options.size()

you don't have to wrap returned result into unmodifiable collections because the data you are returning is not needed by the class which allocated it, so it does not care if caller of that method modifies the list.
That would make only sense when you return abilities list from a Card or card list from a zone (when caller is given a reference to private data but must not modify it)

[RumbleBBU]

Done. Thanks, Max!

[friarsol]

Then I realized that the prices were so high that no-one would play a single quest long enough to unlock more than just a set or two, and no more, ever...

Speaking of which, I've been considering increasing the base sale price and possibly the Capped Sale Limit at the start of the quest. So the player can a bit more funds rolling through from selling cards.