1. Background

On the back of the success of Tetris Madness, Madness Industries has decided to go all out and conquer the preeminent world of digital card games. Searching the archives, Madness Industries has                      rediscovered an ancient Norwegian card game Spill med Troner which translates as Game of Thrones.

A team at Madness Industries has developed a framework for a digital version of Game of Thrones        (GoT); their code works reasonably well, but unfortunately it was built in a rush and was poorly              designed. Madness Industries has recruited you and your team to revise the existing design and             codebase and extend the framework to include the new features required to make the GoT game a hit.

Figure 1: The GUI of GoT game

2. Rules for the Card Game of Thrones

2.1.     Basics

1.  The game is played with a standard 52 card deck without aces (48 cards).

2.  All picture cards have rank 10.

3.   Hearts represent the characters in the game, while the other three suits represent various effects: clubs are attack, spades are defence, and diamonds are magic    which also modify attack and defence.

4.  The game involves forming an effected characters for each of two teams using these effects (attack, defence, magic). An effected character is represented by its character (heart card) plus a sequence of effect cards. E.g. [6H, 3C, 7D] is the character 6H,     with the sequence of attack effect card 3C and magic effect card 7D applied.

5.   The game ends with the two effected characters battling (battle details are below), based on their attack and defence.

2.2.    Attack and Defence

1.  The attack and defence for a character (heart), without added effect cards, are both equal to the card rank. E.g., the character [6H] has attack 6 and defence 6, and the character [QH] has attack 10 and defence 10.

2.  A club effect card adds the card rank to attack. E.g., [6H, 3C] has attack 9 and defence 6.

3.  A spade effect card adds the card rank defence. E.g. [6H, 3S] has attack 6 and defence 9.

4.  A diamond effect card reduces either attack or defence by its rank depending on       whether the card below is a club (attack) or a spade (defence) or a diamond              (whichever one that diamond reduced). Note: the card below cannot be a heart. E.g., [6H, 3C, 5D] has attack 4 and defence 6, [6H, 3S, 5D] has attack 6 and defence 4,    and [6H, 3S, 5D, 2D] has attack 6 and defence 2. [6H, 5D] is not valid and should     never occur.

5.  Attack and defence for an effected character never drop below zero. E.g., [6H, 3C, 10D] has attack 0 (=6+3-10 but can’t drop below 0) and defence 6.

6.   However, if the rank of an effect card (club, spade, or diamond) is the same rank as the card on which it is directly played, the effect of that effect card is doubled. E.g.,  [6H, 6C] has attack 18 and defence 6, [6H, 6C, 6D] has attack 6 (=6+12- 12) and     defence 6, and [6H, 10C, KD] has attack 0 (=6+10-20 but can’t drop below 0) and   defence 6.

2.3.    The Game

1.  The Deal: Hearts are dealt, three to each player. The other cards are dealt together, nine to each player.

2.  All cards are dealt face down, and then all cards are played face up. Note: the         software version of the game deals the cards face up to make it easy for developers to tell what is going on, however automated players should not be able to “see” the  cards of any other players.

2.5.    Strategy

1.   Players will want to add positive effects to their character (heart card) and negative effects to their opponent’s character.

2.   Players will need to decide when to play effects cards and when to pass. Effect cards left at the end of all plays are wasted, however some played effect cards may not      impact on the battle and so are also wasted.

3. Existing Simple GoT Framework

1.   Deals the heart and non-heart cards correctly.

2.   Controls the sequence of play correctly.

3.   Ensures hearts (characters) are played before other cards.

4.   Supports configurations of human and non-human players in any combination to play the game.

5.  Allows humans to select cards by double-left-clicking, select a pile to add the card to by left clicking, and can pass by right clicking any of their cards.

6.   Does not ensure all moves are legal.

7.   Has non-human players play randomly but not all moves are legal and the plays may help the opposition or hinder the player’s own side.

8.   Decides the battle outcomes based only on the unaffected characters (the hearts).

9.   Calculates the score to find the winners.

Don’t just focus on the code provided. We suggest that you and your team follow a process like this:

1.   Play GoT with a pack of cards to make sure you understand the rules.

2.   Download and run the simple GoT Framework ASAP.

3.   Run configurations involving both human and non-human players (look for the attribute humanPlayers to change this).

4.   Refer to the design class diagram provided for the simple GoT Framework and look at the code to get a high-level understanding of what has been provided.

5.   Discuss the Specification for Extended GoT (below) within your team, consider          alternative design patterns/approaches for implementing the changes, and reach       agreement on the approaches to be taken. (You may want different team members   to come up with suggestions for design approaches for different changes.) Document this discussion and the outcomes for your report.

6.  You should consider any complex behaviour you need to develop, and whether a     sequence diagram (perhaps just a rough version on a whiteboard) would help clarify this behaviour. If so, this diagram can evolve into part of your report.

7.   Based on the agreed approach, refactor the simple GoT Framework to make it easy to add the changes. Refactoring involves change the code without changing the      behaviour: don’t forget to test that the behaviour has not changed.

8.   Make the changes while testing, testing, testing.

9.   Generate a class diagram from the final code. Consider if unnecessary detail should be removed and modify it to make sure that associations and other relationships are clearly depicted.

10. Finalise your report and submit.

4. Specification for Extended GoT

Changes must be made to the framework to meet the following requirements.

1.   Calculate the attack and defence values, and the outcomes of the battles, correctly based on the full sequence of character (heart) card and effect cards.

2.   Ensure that all player types (see below) follow the rules of GoT listed above, by         playing a heart (character) only if they are taking one of the first two moves, and by   not playing a diamond (magic) on a heart. This should be checked independently of  the player’s actions with BrokeRuleException being thrown if a rule is violated. Note: if your updated program is behaving correctly, this exception should never be thrown.

3.   Support four player types: human, random, simple, and smart.

a.   Human players behaviour should not change from that supported by the current framework, other than ensuring the player follows the rules.

b.   Random players behaviour should not change from that supported by the current framework, other than making the player follow the rules.

Note: if the random player selects a card and a pile and cannot legally play that card on the pile, the random player should instead pass.

c.   Simple players will play like the random player, but without making plays which directly help the opposition or hinder their own team.

Note: this is an additional constraint on whether the simple player will proceed with playing the selected card on the selected pile.

d.   Smart players must keep track of the cards played and use this information  together with knowledge of their own hand to ensure that they will only play  an effect card E where (1) it would change the battle outcome in their team’s favour if the battle took place straight after playing E, or (2) there is no magic card (diamond) still in play in another player’s hand which could double         reduce the effect of E (the diamond would have the same rank as E).

4.   Load appropriate game parameters from the property files; you decide which ones.  However, you must at least support configuring the player types in the property file   using properties of the form “players.0=smart” for the full set of player types {human, random, simple, smart} and players {players.0, players. 1, players.2, players.3}, and  the two other parameters (seed, watchingTime) appearing in the sample property     files. All properties you add must have defaults provided in the code (see                  setProperty() in main()).

You and your team are to design, implement and test these changes to GoT. You can change the design and code as you see fit, noting that we will build and run your submission without using an integrated   development environment (IDE).1   using property files we provide. As such you must preserve the entry point “GameOfThrones.main()”, meet the property requirements (point 4), and preserve existing text    output and GUI behaviour.

Ensure that your code is well documented and includes your team name and team members in all changed or new source code files.