The final project combines the technologies developed in the Ballworld and
Chat App systems.
- Must involve the interaction between independently implemented
applications across internet-connected machines.
- Must be able to handle an arbitrary number systems connected at once,
not just two or three.
- Must be fundamentally extensible for new features/capabilities.
Don't forget to use your Design Process Overall
ChatApp and Final Project Communications Pathways
The provided code should be automatically supplied through the GitHub Classroom assignment template. The common API submodule needs to be manually added -- See the instructions in Canvas.
Note: you may need to add the JUnit 5 library in order to support the unit tests that are included
with the provided code. Do this if you get errors in the test code
packages. Simply right click the project in Eclipse, and select Build Path/Add Libraries... then select JUnit and then the JUnit 5 system on the following window. Be sure to remove any other
JUnit libraries, e.g. JUnit 5.
The GIS system being used may change from semester to semester and may or may not be required! Check the official instructions in Canvas to see exactly which GIS software development kit (SDK) is being used as well as installation and usage information.
The following requirements are NOT official! Please see Canvas for any modifications to these requirements!
Convention: To avoid name clashes, all implementation code written by a team should be under a package named: "netID1_netID2"
where netID1 is the team "lead". If there is a 3rd teammate, add their NetID to the package name as well.
For this milestone, you and your partner(s)
need to show that you have a well-thought out, coherent design ready for
The due date for Milestone 1 is explicitly set such that the required operationality must be achieved using your Final Project API Design Group's proposed API. This is really just a statement that testing of your proposed API is of paramount importance.
The submission requirements are generally the following and are subject to change -- check Canvas for the official requirements and rubric:
The GitHub commit that is closest to but
not past the Milestone 1 deadline will be considered your Milestone 1 submission and must contain at least the following:
- Prose description of how your game will work, including
typical game play with winning and losing. (35 pts)
UML diagram of the interfaces and implementing classes
A prose description of how your design will implement the
required common API as well as any features specific to your implementation.
The above UML diagram may be imbedded in this document if desired
(recommended!). (20 pts)
Javadocs for the classes and interfaces in the UML
diagram. A minimum detail level of class/interface and method
descriptions is required. Descriptions of fields and input
parameters is recommended but not required. The Javadocs should
be in the form of HTML web pages so they can be easily read, not just the
comments in the code. (15 pts)
The submitted code should have the following minimum capabilities: (15 pts)
- Note that since there is a high probability that a different API will be chosen in the end, the implementation of the game should be couched in API-independent terms.
- Some things to include in the game implementation discussion include but are not limited to:
- The basic classes needed to implement the game
- The messages that the game needs to be sending around
- What processing takes place on the client vs what processing takes place on the server (if any).
- The visual elements needed by the game
- Human player interactions with the user interface and what will happen as a result -- be specific in terms of operations and messages sent!
- What sorts of command-to-command communications (on the same machine) are needed and how those communications will be established.
(10 pts discretionary)
- Note: Since the Final Project API will not be finalized by
the Milestone 1 due date, functionality should be achieved using the
team's Final Project Design Group's API.
- Minimum functionality includes the following plus any other class-discussed functionality if any (as detailed in Piazza posts) :
- Establishing connection between the game server and game clients through the auto-connect-back process.
- Joining a team or some sort of room
- Does not have to be the full team joining process for one's game but enough to demonstrate the capabilities of the API.
- Recommendation: Have different teams in the design group test different aspects of the API's team joining capabilities.
- Simple message sending within a team or room, e.g. a simple text message
- Sending, receiving and processing a message that results in the display of an operational map (full game functionality is not required) on the game client.
For this milestone, you will submit your fully operational
code plus full documentation. The submission requirements are generally the following and are subject to change -- check Canvas for the official requirements and rubric:
- Documentation: (25 pts total)
- Fully detailed and accurate UML diagram and
operational description from Milestone 1 with any changes and additions
as were done since then. (5 pts)
- Full Javadocs, this time including descriptions for
all methods with input parameters and all fields. (5 pts)
- A user's manual that describes at least:
(15 pts sub-total)
- How to start the program, both the program itself
as well as any individual games or processes. (3 pts)
- How to connect to other users (3 pts)
- How to use every feature of the program. (6 pts)
- How to end and exit the program. (3 pts)
- Fully operational code should be committed to the SVN
turn-in repository: (50 pts total -- based on Demo Day feedback)
- System Architecture (5 pts)
- Is the system designed in accordance with the
principles emphasized in the course? Documentation support for
your architecture is very helpful!
- hat section is really about the quality of the design in your code as per the principles and practices covered in the course. Simply "working" is not good enough when developing software. This covers issues such as, but not limited to
- Strong separation of the variant and invariant aspects of the system
- Proper separation of concerns such as in one's MVC design
- Good abstraction of variant processes, such as using strategies, commands and factories rather than conditionals where appropriate.
- Appropriate use of design patterns where applicable, such as using a composite pattern to represent a recursive data structure
- Solid use of classes, interfaces, inheritance and polymorphism to represent the entities and abstractions in the system, e.g. no "god objects".
- etc., etc.
- Percentage of working projects in class (10 pts)
- (10 pts discretionary)
All teams are required to submit a proposal for their game so
that the staff can vet that proposal to make sure it is of reasonable scope and
is doable in the allotted time.
Guidelines for vetting game proposals:
- Game complexity:
- Not too hard – keep the number of things that players have to do to just a handful of operations.
- Not too simple – should be more than just zooming around the map or something where the map and other game play could be circumvented.
- Game play:
- Goals, rules and operations are simple enough to be learned in only a minute or two.
- Winnable in 10-15 minutes
- Operations are clearly described, not vague statements about players doing something. Need to make sure that desired operations are actually feasible.
- Requires actual engagement in the game to play, i.e. can’t be played by simply Googling things.
- Non-trivial team cooperation and interaction required. If based primarily on text messages, then the messages must contain non-trivial information needed to play the game. Non-textual communications are recommended as well.
- Watch for implied issues and requirements, especially to curb cheating/circumventing of the game, such as needing to disable navigation controls.
- Operational issues:
- Algorithmic complexity: make sure any implied calculations are within the scope of the course and aren’t too resource intensive.
- Network complexity: Make sure game doesn’t require excessive network traffic, e.g. first-person shooter type game.
Additional Grading Information:
- A percentage of the Final Project grade will be based on the percentage of working projects
submitted by the entire class.
- A percentage of the final course grade will be based
participation during all design activities, including class and lab
attendence, poll/survey voting and the final project design and testing.
- See the official Demo Day
instructions for the description of what will happen on Demo Day and
what the game evaluation survey will cover.
Not all the material below may be required!
© 2020 by Stephen Wong