Java代写 | COSC 2391/2401, S2, 2020 Casino Style Card Game

本次Java代写是用awt/swing完成一个卡牌游戏

COSC 2391/2401, S2, 2020
Casino Style Card Game

Assessment details
As part of your new implementation you must write a GameEngineCallbackGUI class that is added to the GameEngine via
the existing addGameEngineCallback() method. This class will be responsible for managing all of the graphical updates as the
game is played. NOTE: this class should not actually implement the UI functionality but instead for cohesion it should call methods
on other classes, especially the view. To state another way, it must be the entry point for any UI code resulting from game play, in
order to avoid coupling between the GameEngine and the UI which is counter to the original specification.
This GameEngineCallbackGUI is to be added in addition to the console based GameEngineCallbackImpl from
assignment 1 in order to demonstrate that your GameEngine can work with multiple callbacks i.e. both (all) callbacks are called for
any relevant operation such as nextCard()/result (). NOTE: This is the main reason the assignment part 1 specification
required the GameEngineImpl to handle multiple callbacks! It should also help debugging since you will have the console output
to match against the UI behaviour.
AWT/Swing User Interface
You are to develop an AWT/Swing user interface that implements the following basic functionality:
Add players (including name and initial betting points balance) displaying an error message or dialog for invalid data
Remove Player
Place a bet (per player) including displaying an error message or dialog for invalid bets
Cancel/Remove a bet (i.e. reset a bet to 0)
Players Deal (per player) .. cards are shown in real-time in the CardPanel as they are dealt (see drawing the cards below) with
appropriate delay timing
House Deals – Once all players have bet and dealt the House automatically deals and again their cards are displayed in real time in
the CardPanel
Display updated player balances in the SummaryPanel after the house deal has finished including stating WIN/LOSS per player and
then reset all bets to 0 for the next round
NOTE: You should set your delay parameters to 100 ms for testing and submission.
VISUAL LAYOUT
You have some flexibility with designing the layout and appearance of your interface and should focus on clarity and simplicity
rather than elaborate design. However, to demonstrate competency you should include at least one each of the following and must
also meet the specific requirements in the UI implementation section below.
A pull-down menu (like the standard File menu in Eclipse)
A dialog box
A toolbar
A status bar
A switchable per player CardPanel showing the card graphics as well as the animated and correctly timed deal (see UI
Implementation/Limitations below for more detail)
A SummaryPanel which is always visible which shows player names, their current points balance, their current bet and their most
recent win/loss amount.
A mechanism such as a button for initiating a player deal (but the house deal should occur automatically once all players have placed
a bet and dealt)
Marking emphasis will be on the quality of your code and your ability to implement the required functionality as well as basic
usability of the UI (based on the usability attributes described in the lecture notes).
Your code should be structured using the Model View Controller pattern (MVC) where the GameEngineImpl from assignment
part 1 serves as the model, the listeners represent the controllers as separate classes (each in a separate file placed in the
controller package), whereas the GameEngineCallbackImpl and new GameEngineCallbackGUI are part of a view
package (or sub-packages), as are any additional UI classes such as frames, dialogs, components, menus etc. Furthermore, you must
NOT use static referencing (e.g. no use of the Singleton pattern) and therefore all references required by different classes must be
passed as parameters (e.g. via constructors).
IMPORTANT: Your assignment 2 code should be a separate Eclipse project called CardGameGUI which references assignment 1
via the Eclipse build path dialog. This provides clear separation and helps ensure all of your GUI code (MVC views including the
GameEngineCallbackGUI and controllers) is separate from your GameEngineImpl implementation (MVC model).
Furthermore, all of your GUI code should call your GameEngineImpl implementation via the GameEngine interface only. You
should not add any UI code to the GameEngineImpl with the primary test being that your UI code should work with any
GameEngine implementation (for example our own implementation we will use for testing). i.e. your UI should not require
anything additional from the assignment 1 GameEngineImpl if implemented correctly according to the Javadoc and assignment 1
specification. Finally, your GameEngineImpl should still pass the Validator checks from assignment 1. Another way to think about
it is that any changes to the original assignment 1 project should be to fix missing functionality, not to add anything new.
NOTE: It is a core learning outcome of this assignment to demonstrate that encapsulation and programming to OO interfaces
provides complete separation such that code written by independent parties can work together seamlessly without any change!
UI IMPLEMENTATION/LIMITATIONS
You must only display the CardPanel for a single player at a time, whereby the visible/active player can be directly selected from a
list or combo box (for example a JComboBox in the toolbar).
You should also implement the house as a player in the UI (but they will not be a player in the GameEngine since this is not how it
was designed). Furthermore, the house player is unique in that it cannot bet or deal since dealing is automated as described above.
The house can however be selected so you can see the last dealt cards, and also the house player should be automatically selected
when the house auto deals.
More importantly, since the UI is per player, if a player is currently visible/selected and dealing, when you switch to another player
the UI should stop animating the dealt cards and should instead display the last cards dealt by the player you switched to. You can
however assume that only one player will be dealing at a time so you do not have to handle concurrency in the Game Engine but
you should enforce this in the UI (for example by disabling the deal button during a deal).
The animation, positioning and scaling of the CardPanel is likely the most challenging part of the assignment and should be left until
the end when everything else is implemented correctly. That said it just requires some basic arithmetic (scaling and coordinate
translation) and a bit of patience/determination to get it right ?
Moreover, you can get the main functionality working first using a simple JLabel that is updated for each new intermediate result
(nextCard(…)/nextHouseCard(…)) received from the GameEngineCallback method. You can also refer to the console
logs.
The SummaryPanel should only take up one quarter, to a maximum one third, of the frame with the CardPanel taking the
remainder of the space (excluding any toolbars, status bars etc. which should be compact). Resizing should be appropriately handled
using layout management.
Threads
Although threads will be covered towards the end of the semester, AWT/Swing requires all calls to the UI (any methods in
AWT/Swing such as creating a component, laying out, or updating) to be done on the AWT Event Dispatch Thread. Furthermore,
since the dealPlayer()/dealHouse() methods of GameEngineImpl executes in a loop with a delay (or using a Timer) it
is necessary to run it in a separate thread so it does not lock up the UI.
To achieve this you can use the code below. You don’t need to know exactly how this works for now (although the API docs are
useful here and we will also cover in class) but hopefully you are able to identify how the code is simply using anonymous inner
classes to execute some code on a separate thread!
To call a GameEngineImpl method (such as dealPlayer()/dealHouse()) on a separate thread.
new Thread()
{
@Override
public void run()
{
// call long running GameEngine methods on separate thread
}
}.start();
To update the GUI from the callback ..
SwingUtilities.invokeLater(new Runnable()
{
@Override
public void run()
{
// do GUI update on UI thread
}
});
Implementation Details
IMPORTANT: As with assignment one you must not change any of the interfaces but you may implement any other helper classes
that you need to. A correct implementation should not require any changes to the GameEngineImpl, only the addition of new
AWT/Swing classes to build the UI, in addition to a new GameEngineCallbackGUI.