Further Programming COSC 2391
Further Programming
Hello, dear friend, you can consult us at any time if you have any questions, add WeChat: THEend8_
Further Programming COSC 2391
Casino Style Coin Game
Assignment Part 2: AWT/Swing UI Implementation
Assessment Type: Individual assignment; no group work. Submit online via Canvas→Assignments→Assignment 2. Marks are
awarded for meeting requirements as closely as possible according to section 2 and the supplied rubric.
Clarifications/updates may be made via announcements/relevant discussion forums.
Due date: Due 6:00PM Fri. 18th October 2019. Late submissions are handled as per usual RMIT regulations – 10% deduction
(2.5 marks) per day. You are only allowed to have 5 late days maximum unless special consideration has been granted.
Weighting: 25 marks (25% of your final semester grade)
1. Overview
This assignment requires you to build an AWT/Swing graphical user interface for the Coin Game that reuses your code from
assignment part 1.
You should build on top of your existing assignment part 1 functionality and should not need to change your existing Game Engine
code if it was correct in assignment part 1. You can seek help in the tutelab/consultation to finish assignment part 1 if necessary
(since it is a core requirement of this course that you should be able to work with basic OO classes and interfaces). Furthermore, you
will require a solid understanding of classes/interfaces to write effective AWT/Swing!
2. Assessment Criteria
This assessment will determine your ability to implement Object-Oriented Java code according to a written and visual specification
and incorporating specific design patterns. In addition to functional correctness (i.e. getting your code to work) you will also be
assessed on code quality. Specifically:
You should use MVC implementation for your system.
You should write all your listeners as separate controller classes in the controller package.
You must not use any static referencing (e.g. no use of the Singleton pattern permitted).
You should aim to provide high cohesion and low coupling as covered in this course.
You should aim for maximum encapsulation and information hiding.
You should rigorously avoid code duplication.
You should comment important sections of your code remembering that clear and readily comprehensible code is preferable
to a comment.
Since this course is concerned with OO design you should avoid the use of Java 8+ lambdas which are a functional
programming construct.
You should emphasize basic usability of the UI (based on the usability attributes described in the lecture notes).
You should use extra threads where necessary (based on the sample code provided in this document) to ensure smooth UI
operation that is correct according to the Java API specification.
3. Learning Outcomes
This assessment is relevant to the following Learning Outcomes:
CLO1: Explain the purpose of OO design and apply the following OO concepts in Java code: inheritance, polymorphism, abstract
classes, interfaces and generics.
CLO2: Describe and Document Diagrammatically the OO design of the Java Collection Framework (JCF) and apply this
framework in Java code.
CLO3: Describe and Document Diagrammatically the OO design of the Java AWT/Swing APIs and apply these APIs to create
graphical user interface (GUI) code.
CLO4: Demonstrate Proficiency using an integrated development environment such as Eclipse for project management, coding
and debugging.
CLO5: Describe and Document Diagrammatically common OO design patterns such as Model View Controller (MVC), Observer,
Decorator and apply in Java code.
4. 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 playerCoinUpate()/resultPlayer(). 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.
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 specifying the bet type and displaying an error message or dialog for invalid bets
Cancel/Remove a bet
Players spin (per player) .. both coins are shown in real-time in the CoinPanel as they are spun (using the supplied .png files .. see
details below) with independent timings
Spinner spins – Once all players have bet and spun the Spinner automatically spins and again their coins are displayed in real time in
the CoinPanel
Display updated player balances in the SummaryPanel after the spin has finished including stating WIN/LOSS per player and then
reset all bets to NO_BET
NOTE: You should set your delay parameters to (100, 1000, 100, 50, 500, 50) 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 CoinPanel showing the coin graphics as well as the animated and correctly timed coin spins (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 (including bet
type) and their most recent win/loss calculated according to the betting odds from assignment 1.
A mechanism such as a button for initiating a spin (but the spin should also occur automatically once all players have placed a bet)
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 CoinGameGUI 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!