CS2212 Group Project Specification
Version 1.0
Winter Session 2024
1. Overview
The world we live in is complex and continuously evolving, and education is the key to
understanding and thriving within it. To this end, educational games emerge as innovative tools
that combine the thrill of gaming with the benefits of learning. The rapid growth of digital media
provides an unprecedented opportunity to meld play with pedagogy, resulting in experiences that
educate, engage, and entertain. In this vein, this project invites students to apply the software
engineering knowledge they will gain in this course to the realm of educational game
development.
Educational games, also known as serious games1, are designed with the dual purpose of
entertaining players and imparting knowledge or skills. Unlike traditional learning methods that
may sometimes struggle to captivate learners, educational games leverage the interactive and
immersive nature of gameplay to sustain user engagement. Studies2 have demonstrated that
gamification in education can lead to higher levels of motivation, increased attention spans, and
stronger retention of the learned material compared to conventional instructional methods.
The objective of this project is to create a game that teaches a lesson, life skill, basic ability, or
concept in a way that resonates with the intended audience. In designing your game, whether for
a young child learning arithmetic or a college student mastering complex theories, the goal is to
craft an experience that is not only educational but also enjoyable and memorable.
Your team has the creative freedom to decide the educational goals, target audience, and learning
content of your game. While advanced graphics are not required, a basic Graphical User
Interface (GUI) must be included to enable player interaction. Games that focus on teaching
essential skills such as spelling, reading, and arithmetic are acceptable (if they fulfill the
requirements in this document), even thought they may not have demanding graphical
requirements. Regardless of the path you choose, the game you design should be both engaging
to play and effective in teaching its intended lesson.
This document outlines the general specifications for this project. Separate documents will be
posted to the OWL assignments tab to provide specifications for each project component and
milestone of the project.
1 Wikipedia: Serious Game:
2 De Freitas, Sara. "Are games effective learning tools? A review of educational games." Journal of Educational
Technology & Society 21.2 (2018): 74-84.
2. Objectives
This project is designed to give you experience in:
• Applying the principles of software engineering towards a real-world problem.
• Working with, interpreting, and following a detailed specification provided to you.
• Creating models of requirements and design from such a specification.
• Implementing your design in Java3 and having to deal with decisions made earlier in the
design process.
• Creating graphical, user-facing content and applications.
• Writing robust and efficient code.
• Write good, clean, well-documented Java3 code that adheres to best practices.
• Reflecting on good/bad design decisions made over the course of the project.
The project is intended to give you some freedom in design and programming to explore the
subject matter, while still providing solid direction towards reaching a specified goal.
3. Choosing a Game to Create
When designing your educational game, it's crucial to research existing games for inspiration and
to understand the standards of educational gaming. The following are a few resources where you
can find examples of educational games. Keep in mind that many of these examples may be
far more complex and graphically demanding than what is expected from your team.
BrainPOP's GameUp: This website (https://www.brainpop.com/games/) features a variety of
educational games that cover different subjects. It is a practical resource for seeing how games can make
learning fun and engaging.
PBS Kids Games: On the PBS Kids Games website (https://pbskids.org/games/), you will find a
variety of educational games for younger audiences that cover topics from science and math to
art and music.
National Geographic Kids: The games section on the National Geographic Kids website
(https://kids.nationalgeographic.com/games/) provides games related to geography, animals, and
nature, offering engaging ways to learn about the world.
Funbrain: Visit Funbrain (https://www.funbrain.com/games) for educational games that cover
subjects such as math, reading, and problem-solving. The site caters to different age ranges, from
pre-K through 8th grade.
Coolmath Games: Coolmath Games (https://www.coolmathgames.com/) offers a large selection
of logic and thinking games that reinforce math and strategy skills.
3 Teams may optionally choose to use Python. See point 1 in section 4.2 for details.
Starfall: Starfall (https://www.starfall.com/) is particularly focused on language arts and
mathematics, providing games and activities for pre-K through 3rd grade students.
Sheppard Software: At Sheppard Software (http://www.sheppardsoftware.com), you'll find
hundreds of educational games, ranging from preschool activities to adult brain games. The
graphics are simple and the focus is on learning concepts.
Turtle Diary: Turtle Diary (https://www.turtlediary.com/games.html) has a variety of simple
and fun educational games designed for early learning through elementary school levels.
SplashLearn: SplashLearn (https://www.splashlearn.com/math-games) features math games
with simple interactive elements that are suitable for students from pre-K to grade 5.
Selecting the right game to implement is a critical first step of this project. When selecting your
educational game idea you must consider your resources, the abilities of your team, the course
timeline, and requirements in this document. You will be expected to implement this game so it
is important to select a manageable idea that is not too complex, but also an idea that has enough
depth to fulfill the requirements outlined in the next sections.
4. Requirements
Your project will need to adhere to a collection of functional and non-functional requirements. In
essence, the functional requirements outline what your application will need to do, while the
non-functional requirements specify how you're supposed to go about doing things.
As a team you will also gather, refine, and develop additional requirements specific to your game
but all teams must satisfy the requirements in this section.
4.1 Functional Requirements
Functional requirements include required functionality, as discussed in the sections below. You
must implement all of the required functionality for your project to be considered complete. How
the below functionality is delivered is for the most part up to you.
While we will not be grading visual appeal or aesthetics directly, if things slide to the point
where your application is unintuitive, difficult to use, or unreadable, then this could impact your
overall grade. User experience (UX) and the usability of your application are important factors
that will be considered and are not equivalent to visual appeal or aesthetics.
4.1.1 User Interface
Your application needs to provide a Graphical User Interface (GUI) that players of the intended
age group can navigate easily. This interface should be at least partly mouse based, inform
players about the game state, and responds to their inputs. The following UI requirements must
be included:
Multiple Screens: The game must have at least five distinct screens/pages including: a main
menu screen (requirement 4.1.2), a gameplay screen, an instructional/tutorial screen (requirement
4.1.3), a high score list screen (requirement 4.1.6), and a progress/results screen (simply a screen
that shows the results of the problem/level/stage/challenge). Your team is free to add additional
screens as required.
Mouse-Based Interaction: The interface must support mouse-based interactions, enabling users
to navigate through the game's screens, make selections, and control some game elements
primarily with a mouse. It is acceptable if parts of the game’s core gameplay is keyboard based,
but menus should be primarily navigated via the mouse.
Keyboard Shortcuts and Commands: The interface should include keyboard shortcuts and
commands for common actions to facilitate ease of use, especially for power users or when a
mouse is not the most efficient input method or for accessibility reasons.
Where relevant, include keyboard controls for gameplay actions (e.g., pressing 'P' to pause or
'Esc' to return to the main menu).
Feedback Systems: The UI must provide visual or auditory feedback in response to user actions,
such as clicking buttons or entering commands, to confirm that the desired action has been taken.
Your GUI can be created using a standard library such as Java Swing or JavaFX, be a custom
interface developed by your team, or some combination of the two. It is acceptable to use tools to
help generate and build your GUI code (such as your IDE’s GUI Builder4 or Scene Builder) so
long as you cite their use in your documentation and code.
4.1.2 Main Menu
Your game must have a main menu screen that displays the title of your game and provides
options for the user to select from. These options must include 1) start a new game, 2) load a
previously saved game, 3) tutorial or instructions, 4) high scores, 5) exit. Your team may add
additional options. Each option should take the player to a new screen in your application.
4 Many Java IDEs such as NetBeans, IntelliJ, and Eclipse come with tools or have plugins to assist you with building
a GUI and generating some of the code for you.
The main menu should also display: 1) some graphic or visual that is representative of your
game, 2) list the names of the developer’s who created it (this would be the members of your
team), 3) your team’s number, 4) term it was created in (e.g. “Fall 2024), and 5) mention that this
was created as part of CS2212 at Western University.
4.1.3 Instructions and/or Tutorials
You must include at least one screen with detailed instructions on how to play your game and
use this application. This can be text based, include pictures, or be an interactive tutorial. In all
cases it must be compressive enough to inform players with no previous experience with your
software how to play your game. It should document all major features from the players
perspective (i.e. it does need to include low level technical details).
When creating your instructions or tutorial, you should keep in mind the target demographic for
your game and write these instructions appropriately for their age level.
4.1.4 Game Play and Mechanics
Game mechanics are the rules and systems that govern player interactions and progress within
the game. Your game should have mechanics appropriate for your selected idea. Here are a few
generic functional requirements related to game mechanics that you should include in your
software (keep in mind you will have to gather and develop additional requirements specific to
your game idea):
Scoring System: The game must implement a scoring system that awards points or scores based
on player performance, such as answering questions correctly, completing tasks, or based on the
length of time it took to complete some objective. This score should be traced by your software
and displayed to the player.
Progression Mechanics: Include a system that allows players to progress through levels, stages,
or modules as they achieve predefined educational objectives or reach certain scores. Players
should be able to unlock new levels or content as they progress. You must include at least 3
different levels, stages, modules, or difficulty settings players can progress through.
Educational Challenges: Your game must include some type of educational challenges,
puzzles, or tasks that are tied to the learning objectives of the game. These should be appropriate
to your target demographics age level and the topic of your game.
Response to Player Input: The game must respond to player inputs, such as mouse clicks or
keyboard commands, by executing in-game actions like making selections, moving game
elements, or navigating through content.
Feedback for Correct/Incorrect Actions: Implement clear and immediate feedback
mechanisms to inform the player of correct or incorrect actions, reinforcing the educational
outcomes.
Time-Based Elements: If applicable to the game's educational goal, include time-based
challenges where players must complete certain tasks within a time limit. This maybe part of the
scoring system if points are time based.
Lives or Attempts: For games that involve a system of lives or attempts, there must be a system
for tracking and updating the number of lives or attemps the player has remaining.
4.1.5 Save/Load Game State
It is important to provide players with the ability to save their progress, which allows for a
learning experience that respects their time and mirrors the incremental nature of education. To
achieve this, the game must feature a Save Game State mechanism that specifically captures the
player's last significant progression point. This could be the completion of a level, the mastery of
a particular skill set, or reaching an educational milestone within the game's content. The
primary goal is to enable players to resume their progression from the most recent checkpoint.
You are not required to save every detail of the gameplay session, this can be as simple as saving
a single number that represents the last level, stage, or problem the user was on.
To facilitate this, you can either automatically save progress after a set check point or provide
players with a manual save option that is easily accessible from the main game menu, within a
pause menu during gameplay, or elsewhere in the GUI.
When restarting the game, players should have the capability to load their previously saved state.
This loading process should bring the player to a logical point in the game that allows a smooth
continuation of both learning and gameplay, without backtracking through content they have
already mastered.
A clear confirmation message should be displayed each time the game state is saved, reassuring
players that their progress has been successfully recorded.
When designing your save system, please keep the multiple player requirement (requirement
4.1.x) in mind. Each player should have a way to save their progress independently of other
players. This could be provided through a set number of save slots, allowing the user to select a
specific save file, or through a user/account system.
4.1.6 High Score Table
The game should incorporate a High Score Table that maintains a list of the top player scores
achieved. This table provides players with a sense of accomplishment and a benchmark for
success, incentivizing them to improve their performance. The High Score Table must display
the player's name or initials alongside their score (as per the scoring system described in 4.1.4),
and it should be accessible from the main menu (requirement 4.1.2) and/or at the completion of a
gameplay session. It must be capable of storing and displaying at least 5 entries.
The High Score Table should be designed to update automatically as new top scores are attained,
removing the lowest score from the list when a new high score is earned that surpasses it. It must
differentiate between individual players' scores in a clear and organized manner, allowing for
quick and easy comprehension of one’s standing relative to others. This high score list should be
persistent and not be lost when the game is restarted.
The high score list can be local to the computer the game is installed on and stored in a file. The
file format is up to your team.
4.1.7 Multiple Players
Your game must support multiple players. Players should enter their name, initials, username, or
email (which one is up to you) when starting a new game. This identifier should be used in the
high score table (requirement 4.1.6), saved in the save state (requirement 4.1.5), and used for
tracking metrics for the instruction in recruitment 4.1.x.
You are not required to implement a full account or login system. Simply asking the player their
name, including it in the save state (requirement 4.1.5), and tracking it as required in the other
requirements is sufficient.
4.1.8 Instructor Dashboard
In addition to supporting players, your software should also have a mode that will display
metrics to an instructor or teacher so they can track their students progress in the game. At a
minimum, these metrics should include each players current score and progression (e.g. what
level, stage, problem, module, etc. they are on) and what levels/stages/problems/modules they
have already completed.
Your may include additional metrics if you wish such as number of attempts, time spent on each
level/stage/etc., aggregated statistics of all players, and so on but this is optional.
Protect this mode with a password so normal players can not access it. The password may be
hardcoded or customizable. It does not require proper security (e.g. password hashing).
4.1.9 Debug Mode / Level Selection
To make development and testing easier, your game should also have a mode for
developers/testers that enables them to jump to a specific level, stage, problem, module, etc. with
out completing previous progression points that would normally be required.
This mode should be protected by a password, key combination, cheat code, or secret button/UI
element that normal players would not typically find.
You may add additional features to this debug mode that you find useful including cheats,
display of additional debugging information, editing or deletion of save states, map/level editor,
or any additional tools that you would find useful for debugging but this is not required.
4.1.10 Housekeeping & Error Handling
Your application also needs to do basic housekeeping things that are part of any decently put
together application. For example, the user must be able to exit your application cleanly and data
must be saved correctly on exit such that it is available the next time the application is started
(e.g. save states should be persistent, instructor metrics should not be lost, and so on).
If you allow the user to minimize or maximize the window, UI elements should scale correctly. It
is ok if you disable this (allowing the user to minimize or maximize the window) and force the
game to be full screen or a set window size.
Any errors that could be raised by your application should be handled and clear messages in
simple English should be shown to the user, that may help them understand and correct the error.
Ideally, your application should avoid crashing without explanation. Any user input that could
potentially be incorrect or cause faults in your software, must be validated and checked for
errors.
You may add other housekeeping functions as you see fit to help support your application. How
you choose to make these available to the user is up to you.
4.2 Non-Functional Requirements
Your application will need to adhere to the following non-functional requirements. These
requirements will be taken into consideration in the assessment of your project.
1. The application must be developed in Java 19 or newer. Teams may optionally decide to
use Python instead, but all team members must agree to this in their team contract. Please
keep in mind that most examples in class will be for Java and Java based libraries and
tools. Using Python could put you at a disadvantage, so please consider this carefully.
2. Your game must utilize an object-oriented approach and make use of design patterns.
You will be required to explain which design patterns you are using and why.
3. The educational content of the game should be accurate, relevant, up-to-date, and
appropriate for the target age group. Any instructional material must be derived from
credible sources and not contain any inappropriate content. Educational content should be
presented in a manner that is engaging and fun, it can not simply be an electronic quiz.
4. The application is required to have a Graphical User Interface (GUI). This interface must
be user-friendly and aligning with best UX practices to ensure intuitiveness and ease of
navigation. It should present a cohesive design with clear labeling and a consistent visual
language to minimize user effort and facilitate engagement. The GUI's effectiveness will
be part of your project grade.
5. The application must store all data (e.g. save states, high score table, etc.) locally and not
require an internet connection. The file format is up to you, but some good options are
JSON, XML, CSV, or TSV. Some of these formats have standard Java framework
methods or third party libraries to handle them for you, others will require your own code
for working with them. While a third-party library might make some things easier or
more efficient, they can also be complex and difficult to use, costing you more time in the
end than you saved. A database (e.g. SQLite, MySQL, etc.) can only be used if you are
storing the data locally and no internet connection is required (using a database is
strongly discouraged for this project as it will add unnecessary complexity).
6. Your game should not use any third-party libraries that are not freely available. All tools
and libraries used must be easy to obtain and install (or ideally included with your
application). The TA marking your project will need to be able to run it to test it, so you
will be responsible for providing instructions on compiling and running your application
including any required libraries.
7. All code and files for your project must be stored in the Bitbucket Git repository created
for your team (details on this will be announced once available). Your team must
actively use this repository and not simply commit the files at the end of the project.
8. All design work and diagrams for your project must be stored and developed on
Confluence (details on this will be announced once available).
9. All tasks and issues related to your project must be tracked on Jira (details on this will be
announced once available) and be updated as the project progresses.
10. Your code must be commented using Javadoc (or equivalent if your team is using
Python). At a minimum every function/method should have a comment and every file
should have a comment at the top explaining it’s purposes, author, etc. Code generated by
a tool does not need to be commented other than a comment clearly citing the tool used to
generate it. Any code not created by your team members must have a comment citing it’s
source.
11. The majority of your code should be unit tested with a sufficient number of JUnit 5 tests
(or equivalent if your team is using Python). Code that can only be tested via a GUI
actions or events does not need to be unit tested.
12. As a team you must choose and follow coding conventions and styles that you adopt (e.g.
naming things, indentation, etc.). You must remain consistent in applying those
conventions and styles across all files in the application.
13. The application must be executable on a Windows 10 system with a standard Java
installation (Java 19 or newer, unless using Python), and each team member must be able
to compile it and run it from a development environment they have access to. All team
members must use the same development environment and tools as agreed to in your
team contract.
14. The application must be well self-contained and not create, modify, or delete files outside
of the directory in which the application is installed, and subdirectories of this
directory. Simply put the application should not alter or delete files that do not belong to
it or were not created by it.
15. The application must present a visible response to every user action. Erroneous actions or
actions that could not succeed for some reason must be met with a useful, professional
error message.
16. The file size of the project as a whole should be under 1 gigabyte.
17. The application should run efficiently and not use unnecessary computing resources. The
interface should be responsive and not “lag” or freeze while the user is playing the game.
18. Your application must take accessibility into account when designing the user interface.
Allowing tasks to be completed with both a keyboard or mouse would be ideal, as well as
ensuring UI elements have a logical tab order. Colour use in the UI should also be
carefully considered (e.g. for colour blind players).
19. Your code should be maintainable and as reusable as possible. Code should be structured
to allow for easy updates and maintenance.
20. All content in the game, supporting documentation, design work, comments, etc. must be
written in English. While your spelling and grammar will not be graded directly, any
work that is unclear, incomprehensible, or otherwise not easily decipherable by the
marker will be assigned a zero grade. All communications between team members should
also be in English.
21. The application must be otherwise designed with sound software engineering principles
in mind as discussed in the course.
You are also required to gather, refine, and document additional non-functional requirements
related to your specific game idea and educational objectives.
5. Assessment
5.1 Teaching Assistant Marking
Your project will be assessed at set milestone throughout the term (tentative due dates for these
project components are included in the course syllabus) as well as at the end of the term.
Teaching Assistants (TAs) will grade each project component based on a rubric provided by the
course instructor. In addition to assessing the work submitted, TAs will also assign a grade for
project management. Project management includes how well you function as a team, your use of
the Atlassian software, compliance with your team contract, your team minutes, your team’s
attendance at meetings, how tasks are assigned on Jira, management of your code on Bitbucket,
and your use of Confluence to document your software.
At the end of the term, you will meet with your assigned TA for acceptance testing where you
will demonstrate your software and show how it meets each of the requirements in this
document. All team members must be present for this meeting and your performance during this
meeting will be part of your Implementation and Delivery grade.
5.2 Peer Review
At the end of the term, you will assess and also be assessed by your team members in a peer
review. This peer review is worth 10% of your final grade.
Your team will also be responsible for creating a short video that demonstrates your software.
This video will be shared with at least 4 other teams. These teams will provide a peer assessment
of your work based on the video. This peer assessment will compromise part of your
Implementation and Delivery grade.
5.2 Bonus
Teams that 1) significantly go beyond the requirements outlined in this document, 2) clearly put
extra effort into the project, 3) do not do so at the cost of the quality of their software, and 4) are
assessed highly in their peer review by other teams may have a small bonus of not more than
15% added to their Implementation and Delivery grade (this can overflow into your final grade
but not make your final grade go over 100%). The exact amount will be at the sole discretion of
the course instructor and will only be given if the team clearly goes above and beyond what is
expected and scores higher in peer reviews than most other teams. In most cases where a bonus
is given it will be a partial bonus mark (less than 15%).
Simply having one extra minor feature or putting a little extra effort into one requirement is not
enough for this bonus. It must be clear that significant effort went into the project in all aspects
beyond what was required, and this must be acknowledged in both the peer reviews of your work
and the assessment by your assigned TA/instructor.
