Rather than "Select Winner" just cast off two contestants

[Nava2]

Simple to implement, will work.

Why not do it this way?

[ghost]

Sure. It makes sense. We can still refer to it as "Select Winner" for the admin and client and whatnot, but I don't see any problem with actually storing them as cast off contestants.

[JonDemelo]

The issue lies with the fact that in Survivor, they make it clear that in the end, you are not voting for the cast off, but instead for the winner. It's actually a very important aspect of the game. Furthermore, I don't see what this will add to what we already have, since what we already have is ready to go for the assignment. Remember, there's still the final week pick. This final week pick is for the single winner, and what you are suggesting makes it harder and more time consuming, and imo worse programming, to deal with. Right now, if you take a look at the allocate points method in GameData, you'll see everything is already working as needed, for all three of the "vote phases", and is only waiting for bonus to be implemented to be 100% ready.

[JonDemelo]

^^ to further clarify my reasoning:

Before the last week, there is one cont castoff, which is then compared to Ll the user's choices, thus determining if they get the weekly 20pts. also, every week, each user's ult pick is compared to the cast off, and if they are the same, the users ult choice is cleared. In any case of either a weekly or ult pick being empty upon week advancement, they are randomly selected.

Thus, so far there only needs to be one cast off per week on the admin side.

Now onto the final week.

In this week, users no longer pick whom they think will be cast off, but instead vote for both who they think will win this week, alongside their ult choice. The ult choice works exactly as it has previously, the only difference now is that when the user gets the right "winner" choice, they get 40pts instead of 20pts. All this required (it's already done) was a simple isFinalWeek() check, then 40, else 20.

I don't see why this isn't ideal.

[Nava2]

I totally commented on this after and it didn't go through.

Anyway, so I agree with you, my grievance is that we now have the cast off button serving two purposes. I would rather see another button be grayed out the entire time and be activated after.

Not against this after your first explanation. :)

[JonDemelo]

I like your thinking with a new button. Maybe add a disabled "select as winner" button below "cast off" which only becomes active during the last week. It would call the exact same methods as "cast off".

[Nava2]

Exactly! Keeps with the "one button one action" philosophy. On Mar 27, 2012 1:40 PM, "Jon Demelo" < reply@reply.github.com> wrote:

I like your thinking with a new button. Maybe add a disabled "select as winner" button below "cast off" which only becomes active during the last week. It would call the exact same methods as "cast off".

---

Reply to this email directly or view it on GitHub:

https://github.com/CS2212-2012-G2/SurvivorPool/issues/74#issuecomment-4721998

[JonDemelo]

Yeah, Anything else would of only made us do more work then we needed.

[JonDemelo]

I took a look at your recent commit, which included the "casting off" of the two "non winners", and I had some disagreements at first. However, we aren't expected to be exactly like Survivor, so I don't mind it as much. So I think it's pretty good where it is right now, and I'd be fine with this being the final edition (i'm sure there's a few tweaks in terms of state changes or persistance, but as a whole).

If your wondering why I think it's not 100% actually how survivor works, is because the idea of being in the "final three" comes with the concept of "never being cast off", as they aren't actually cast off in any form. This is why I don't think it's representing exactly what Survivor is about, but clearly she's not being so picky about this kind of stuff so what we've got is completely okay with me.

I vote closing this issue.

[Nava2]

Yeah, I see where you are coming from. But in keeping it easy, it makes sense to just force cast off the two. That way when we allocate the pts it will work properly.

Uhm, anything else need to happen after that selection is made? I mean does the general panel have a "finish game" mode?

[JonDemelo]

see #75. I'll add what's inside the label within an if after the final advancefinalweek is pressed. Everything else is dealt with, other then our overarching issue with state persistance after exiting and reopening the program.

[Nava2]

I'm thinking this can be closed?

Pretty sure its off topic now anyway. If we need the rest, open a new issue! :)