Issue 290: Quest Rewards Based on Deck Difficulty

[Doublestrike]

Was looking for something small to help out with and thought this would be simple. Lo and behold, it wasn't.

Turns out there is a hard-coded quest preferences class and also a quest preferences file. Then there's another "QuestRewardsUtil" that is in there sometimes. Then, base credits for a win in the file is 25, and in the code is 10.

So, what did y'all have in mind? It looks like this is in transition, perhaps I should find a new issue?

[Sloth]

Was looking for something small to help out with and thought this would be simple. Lo and behold, it wasn't.

Turns out there is a hard-coded quest preferences class and also a quest preferences file. Then there's another "QuestRewardsUtil" that is in there sometimes. Then, base credits for a win in the file is 25, and in the code is 10.

So, what did y'all have in mind? It looks like this is in transition, perhaps I should find a new issue?

I guess no one really has a clue about what is currently being used (I think Sol raised the base reward, so maybe him), but clearly all hard-coded quest preferences should be removed.

I would love to see quest rewards being based on deck difficulty to give a reward for playing against the very hard opponents (I changed them back to being always optional).

I can imagine the rewards being: 25, 50, 100, 300.

[friarsol]

Ah yea, I keep forgetting there are hardcoded values. I'd say completely remove anything hardcoded. And pull everything from the preferences file. Then you'll just need to add a line for the different difficulties. I'm fine with Sloth's suggested values. Harder opponents deserve better than linear rewards.

Edit: So the last time I did any work in this area there is actually two different places that use these values. One to determine how many rewards are given, and the other to tell the user how much rewards they won. Feel free to combine this all into one area, and use all the values from the prefs file.

[Max mtg]

QuestPreferences.java has default values hardcoded. They are overriden by the file if there is a file and corresponding values in it.
QuestUtilRewards.java contains no hardcode for rewards at all - it has only lucky coin, estates multipliers and threshold of turns hardcoded

Feel free to combine this all into one area, and use all the values from the prefs file.

They were combined a few weeks ago.

[Doublestrike]

Then you'll just need to add a line for the different difficulties.

That's what I envisioned at the start...easy peasy.

They were combined a few weeks ago.

I'm still seeing some repeated code in a few files, which I may consolidate for clarity. Do you foresee a problem with this?

=====

OK so my plan of attack is:

1) knock out the hardcode vals.
2) consolidate the repeated code.
3) add a linear trend for base reward vs. opponent difficulty.

Thanks for the info everyone.

[timmermac]

Does this mean no more changing the amount of credits you start a quest with or changing the amount of cards you start with or win after a match?

[Doublestrike]

@Timmermac - There's an amount of credits you receive for winning a match with no special conditions (the most basic type of win). That's what this is targeting. Currently, for an easy win, you'll get 10 (or 25) credits, which is the same for a very hard win. Obviously, this is a little funky and needs to be updated.

[Max mtg]

They were combined a few weeks ago.

I'm still seeing some repeated code in a few files, which I may consolidate for clarity. Do you foresee a problem with this?

Where exactly?

[Doublestrike]

Let me get back to you later when I'm looking at the code. I won't make any consolidating changes until we discuss.

I've got to stop getting on this forum at work it's very distracting.

[Doublestrike]

OK so I've had a good look at the code and here's my take:

1) Hardcoded vals - as Max previously stated, these are used if the file is gone/incomplete. If they're removed, the preferences file must be built perfectly. So, I'll wait for a consensus here for a day or two before I move on that. Personally still leaning toward no hardcode, mainly to avoid documentation and updating snafus.

2) Repeated lines - QuestUtilRewards and Gui_WinLose have a few lines with similar content, but are required to handle model/view stuff. So, repeated lines is no longer an issue. However, the suspicious feeling I had there turned up a different problem, see below.

3) Increasing rewards - no worries there will fix soon.

===========

New "problem": the quest reward GUIs are in Gui_WinLose. It seems to me that reward GUI classes for different game modes should be in the same package as that game mode, not in the general win/lose handler.

Further, it looks like QuestUtilRewards can be used as the model (perhaps with a different name) and then the code in Gui_WinLose can be shifted to a view class.

I'm happy to do this - thoughts?

[Max mtg]

OK so I've had a good look at the code and here's my take:
1) Hardcoded vals - as Max previously stated, these are used if the file is gone/incomplete. If they're removed, the preferences file must be built perfectly. So, I'll wait for a consensus here for a day or two before I move on that. Personally still leaning toward no hardcode, mainly to avoid documentation and updating snafus.

I would not remove these defaults, but have no reasons to object too.
In that case user should be somehow notified when he has a malformed preferences file, where some values could not be read.

2) Repeated lines - QuestUtilRewards and Gui_WinLose have a few lines with similar content, but are required to handle model/view stuff. So, repeated lines is no longer an issue. However, the suspicious feeling I had there turned up a different problem, see below.

While QuestUtilRewards counts money, Gui_WinLose is composing a message. I didn't find a way how to eliminate that similiarity in code. Maybe move number of turns to a constant?

New "problem": the quest reward GUIs are in Gui_WinLose. It seems to me that reward GUI classes for different game modes should be in the same package as that game mode, not in the general win/lose handler.

Further, it looks like QuestUtilRewards can be used as the model (perhaps with a different name) and then the code in Gui_WinLose can be shifted to a view class.

I had a similiar thought about Gui_WinLose. The what stopped me was that the form Gui_WinLose is used in all other game modes.

How can QuestUtilRewards become a model? It holds no data itself, it's just a set of functions that were littering QuestData, the model.

[friarsol]

OK so I've had a good look at the code and here's my take:
1) Hardcoded vals - as Max previously stated, these are used if the file is gone/incomplete. If they're removed, the preferences file must be built perfectly. So, I'll wait for a consensus here for a day or two before I move on that. Personally still leaning toward no hardcode, mainly to avoid documentation and updating snafus.

I would not remove these defaults, but have no reasons to object too.
In that case user should be somehow notified when he has a malformed preferences file, where some values could not be read.

Doublestrike, maybe try it like this: We have a "default quest.preferences" maybe called, "questrewards.dat" this will be the default quest.preferences. Then if a user wants to actually tweak what they start with, they can change the quest.preferences file. If a quest.preferences file exists, we use that. Else, we use questrewards.dat (and further down the road, possible do a checksum on it for stricter playing modes (Ladder where everyone needs the same starting data.).

If the quest.preferences is poorly formed we alert the user that we are switching over to questrewards.dat. If questrewards is poorly formed, we alert the user that's no good.

[silly freak]

you can even put the default file inside the forge .jar and access it as:

Code: Select all

Thread.currentThread().getContextClassLoader().getResourceAsStream("path/inside/jar");


there should be no problem with a malformed file inside the jar. if there is... that's no good

[Doublestrike]

I'll walk backwards:

Then if a user wants to actually tweak what they start with, they can change the quest.preferences file. If a quest.preferences file exists, we use that. Else, we use questrewards.dat

Actually, this is sort of what's in place already, just hardcoded. If it's quite important, I can move those into a file, just say the word.

I'm surprised the user is "allowed" to do this - seems a lot like a cheat. Not sure of the "official" stance on that.

How can QuestUtilRewards become a model? It holds no data itself, it's just a set of functions that were littering QuestData, the model.

My current understanding of "model" is a class that pulls together values for the view to display. For a QuestEvent win/loss, one view (Gui_WinLose) could use two models and a sub-view:
- QuestData, holding long-term "save-able" information
- A quest rewards model, to chase down short-term rewards specific to a QuestEvent
- A quest rewards sub-view, which is triggered when necessary by parent.

Further, this structure can be used in future quest events, such as Ladder, Bonus Rounds, or something. Whaddaya reckon?

While QuestUtilRewards counts money, Gui_WinLose is composing a message. I didn't find a way how to eliminate that similiarity in code. Maybe move number of turns to a constant?

If the above architecture is a go, I'll spend a few hours exploring this - I'm sure there's an elegant solution.

For future game modes (puzzle, multiplayer, gauntlet, you name it) I think we'll definitely need a universal win/lose gui, with a rewards model/subview depending on the game type ("You've unlocked Puzzle 36" or "First win against 7 players - here's a cookie").

[Max mtg]

I used to develop software in ASP.net MVC framework - there "a class that pulls together values for the view to display" was called controller, while models were representations of some real-life entities with a few methods on them

I'd love to see there a single window showing rewards after the match instead of some three to five messageboxes. So, go on, if you're about to make it. Even separating the quest rewards display code as it is now from the WinLose window would be fine.

Ok, I wish you best of luck (with exploring and finding an elegant solution) - no kidding.