magarena icon indicating copy to clipboard operation
magarena copied to clipboard

Differentiate between "win the game" effects and "Iose the game" effects

Open Fulmene opened this issue 8 years ago • 14 comments

This might not be a very big issue since it affects only 2 cards. Card effects that replace game loss, Lich's Mirror and Exquisite Archangel, will not apply for effects stating that their opponent wins the game. But as far as I can tell, there is no way to differentiate them from effects that make those cards' controller lose the game.

Fulmene avatar Jan 20 '18 20:01 Fulmene

Effects which replace your game loss, don't prevent an opponent from winning. Although you do technically lose, it's not a "target player loses the game", or getting 10 poison counters type of effect; your opponent is winning the game instead. (That's why Abyssal Persecutor makes sure you can't 'accidentally' win by your opponent losing) Lich's Mirror won't trigger when Barren Glory triggers, for example, but will protect against Phage the Untouchable

ShawnieBoy avatar Jan 21 '18 00:01 ShawnieBoy

Sorry, I wasn't clear enough.

What you said is how it works in the real game. However, in Magarena, cards that say its controller wins the game do a LoseGameAction on their opponent as seen in the scripts of Battle of Wits, Coalition Victory, Mechanized Production, and Near-Death Experience, which will trigger Lich's Mirror and Exquisite Archangel.

I also tested Lich's Mirror with Barren Glory and it did trigger. gameplay-report.zip

Fulmene avatar Jan 21 '18 12:01 Fulmene

Ahh, I see what you mean now. Sorry - Yes, you're right. I've never really liked the LoseGameAction for win conditions. You winning and your opponent losing are two separate although related events. If I remember rightly, last time I had a look at this, the issue is with how it all fits in with the AI (Which is more @melvinzhang's area). In reality there should be a WinGameAction as well.

ShawnieBoy avatar Jan 21 '18 12:01 ShawnieBoy

Should be fine to have a WinGameAction as well so that we can move the direct wins to this so it doesn't trigger lose game replacements.

melvinzhang avatar Jan 21 '18 14:01 melvinzhang

What it does, would be analogous to the current LoseGameAction, i.e. it would be to set the losing player as the opponent. i.e. WinGameAction(p) = set losing player as p's opponent.

melvinzhang avatar Jan 21 '18 14:01 melvinzhang

The MagicGame.getWinner() should be able to prioritise a player set as a winner over a player set as a loser. I think it would be best to have two end game results: A player winning or a player losing.

ShawnieBoy avatar Jan 21 '18 14:01 ShawnieBoy

It wouldn't be possible to set both, since actions are performed serially.

melvinzhang avatar Jan 21 '18 14:01 melvinzhang

What happens is the last action before the isFinished check takes place would be the result. Assuming somehow in a single event, A wins and B wins. Then the result is B wins.

melvinzhang avatar Jan 21 '18 14:01 melvinzhang

I was thinking more that there should be a way of setting a player as a Winner, instead of setting the opponent as a Loser. So if A 'Wins' by a trigger, B isn't set as a loser unless they also 'Lose' by a trigger

ShawnieBoy avatar Jan 21 '18 14:01 ShawnieBoy

Recording the loser is the current representation of the result, it does't mean B lost due to a game effect. The later is only when LoseGameAction was applied on B.

melvinzhang avatar Jan 21 '18 14:01 melvinzhang

Yes, I'm just saying that we should be recording a winner as well, where it is separate from an opponent losing. A game would therefore have 4 different finishing states:

  • Player A Wins
  • Player B Wins
  • Player A Loses
  • Player B Loses

ShawnieBoy avatar Jan 21 '18 14:01 ShawnieBoy

Why differentiate the end state where "A won the game" from "B lost the game"? Note that as discussed, we should differentiate an effect which make A win, from an effect which makes B lose.

melvinzhang avatar Jan 21 '18 14:01 melvinzhang

MagicGame.getWinner() is only checking for losers and determining the opponent as the winner. If there were a getWinningPlayer() and setWinningPlayer() separately from LosingPlayer versions it would better reflect the variety of ways that players can win or lose a game. As currently there's only an emphasis on the loser, and losing states. However winning states should really be attached to the winning player.

ShawnieBoy avatar Jan 21 '18 14:01 ShawnieBoy

I also don't think it's necessary to differentiate the end state unless we're going to support draw, which I imagine would complicate the AI.

Fulmene avatar Jan 23 '18 06:01 Fulmene