Software Development (202001064)
Programming (202001066)
Programming Report – Exploding Kittens
Maia Souvannasouck, 3171825,
[email protected] (Optionally you can add a screenshot of your TUI/GUI in this title page)
January/2023
1.1. Class Diagrams……………………………………………….….………3
1.2. Requirements Implementation Map……………………………….……..4
1.3. Model-View-Controller Implementation………………………….…….6
1.4. User Interface……………………………………………………………8
2.1 Unit Testing……………………………………………………………….10
2.2 System Testing……………………………………………………..……15
Academic Skills Chapter (Mihnea Ambrus)
4.1 Time Management and Procrastination Avoidance…………………….15
4.2 Strengths and Weaknesses…………………………………………..…..16
4.3 Checkpoint Meetings……………………………………………………17
Academic Skills Chapter (Maia Souvannasouck)
4.1 Time Management and Procrastination Avoidance…………………..….17
4.2 Strengths and Weaknesses………………………………………………..18
4.3 Checkpoint Meeting………………………………………………………18
Appendix……………………………………………………………………..19
2
Greetings to our Exploding Kittens game presentation! In this report, we aim to unveil the
intricate process behind our game. Join us as we analyze our thought process and reveal the
meticulous planning that led us to the pinnacle of our game development.
1.1. Class Diagrams
3
Image1: class diagram for ExplodingKittens game
In this simplified diagram, I've depicted the connections between classes along with their
main methods. The aim is to facilitate an intuitive understanding of the relationships among
the classes. Additionally, I've included a diagram generated by IntelliJ IDEA to complement
the presentation(see image 5 from appendix)
1.2. Requirements Implementation Map
Requirement 1: The server monitors the client connection through a ServerSocket. It accepts
and manages new client connections within its run() method, while GameManagerNetwork
class orchestrates the state of the game. Each player is represented by a Player interface,
which can be either a HumanPlayer or a ComputerPlayer.
The client application establishes a connection to the server utilizing a Socket. It
offers a text-based user interface through the ClientTUI class, enabling users to interact with
the game(writing commands).
Overall, the client-server architecture allows multiple clients to connect, play the
Exploding Kittens game, and interact with each other over the network. The client and server
components work together to ensure a seamless gaming experience for the players.
Requirement 2:The server initiates a game through the client-server relationship. Clients
establish connections with the server and provide their names. Upon receiving the client
names, the server creates a new GameManagerNetwork instance with the players. Next, the
ClientTUI prompts clients to enter a command to commence the game. Once a client inputs
the command "SG", the game begins.
In the handleUserInput method of ClientTUI, input is processed and separated if
necessary before being passed to the ClientHandler class. The handleCommand method
within ClientHandler manages these commands.
4
During gameplay, clients who encounter an explosion are removed from the server.
The last remaining client is declared the winner, and a congratulatory message is displayed on
the server console.
Requirement 3: In your project, you've implemented a feature where a computer player
automatically joins the game if there's only one client connected to the server. When a client
connects to the server, the server keeps track of the number of players currently connected to
the game.f there's only one client connected to the server (i.e., the player count is 1), the
server automatically introduces a computer player into the game.
Requirement 4: We utilize a Server TUI (Text User Interface) that is invoked when the server
is running. It waits for input to specify the server port, creating a server once the port is
provided. Additionally, we have a ClientTUI class activated when the Client class runs,
prompting users to input the IP address and port number. Once the clients are connected, the
Server TUI is invoked again to display the connected clients and so on.
Once the game begins, the ClientTUI displays a message prompting each client, in
turn, to enter a command. Subsequently, it calls the method handleUserInput for further
processing and action.
Additional feature 1: The first additional feature implemented is the chat functionality. In the
ClientTUI class, whenever prompted to enter a command, users must type "SM" followed by
the message they want to send. The handleUserInput method in the ClientTUI class processes
this message and invokes the sendMessage method from the Client class. Below is a rewritten
explanation
Additional feature 2: The second additional feature we implemented is the ability to play
special combos. This feature builds upon the existing functionality of playing combos, with
similar logic. The method for playing special combos takes an array of indexes and the
targeted player as parameters. Within this method, it checks whether you intend to play 2 or 3
cards of the same type. If you choose to play 3 cards of the same type, you can specify which
card you want the respective player to give you in return.
5
To trigger this action during gameplay, players are prompted to input "PCO" followed
by the indexes of the cards they wish to play, along with the index of the targeted player. This
input is processed within the handleUserInput method of the ClientTUI class. Subsequently,
the PlayCombo method within the GameManager class is invoked to execute the desired
action.
Note: We have a single issue with the game: when an action card is played, it should be
possible for all the players to play the “nope” card over the respective action card. However,
if the current player plays that action card, he is not able to play a “nope” card over his
action. For the rest of the players it works good.
1.3. Model-View-Controller Implementation
The structure you've described follows the Model-View-Controller (MVC) architectural
pattern, which is a widely used design pattern in software development for separating
concerns and making the codebase more organized and maintainable. Let's break down why
this structure is beneficial and why each package is structured the way it is (see image
2&3&4 from appendix):
Main Package: group30.ExplodingKittens:
This serves as the main package for our project, containing the core components of our game.
It's a good practice to namespace your project to avoid naming conflicts with other libraries
or projects.
Client Package:
Contains classes related to the client-side functionality of the game.
Client, ClientTUI, and ClientView are responsible for handling client connections, user
interfaces, and interactions with the server.
6
CommandNames provides shortcuts and constants for communication between the client and
server, enhancing code readability and maintainability.
Exceptions Package:
Holds custom exception classes used in your project, promoting error handling and
robustness in the codebase.
Isolating exceptions into their own package helps organize and manage error handling
effectively.
ExplodingKittens Package:
This package contains several packages which holds the exploding kittens game
Application Package: contains the Game class which helps in running the game.
Models Package: Contains data models such as Card and the Player interface:
PlayerModels Package: Implements concrete player classes like HumanPlayer and
ComputerPlayer, which adhere to the Player interface, facilitating polymorphic behavior and
easy player management.
Test Package: Contains test classes to ensure the correctness and reliability of our
game logic.
UI Package: Holds user interface components like the Text User Interface (TUI) for
the local game, separating user interaction from the core game logic.
Server Package:
Contains server-side components responsible for managing game sessions and
communication with clients.
ClientHandler, GameManagerNetwork, and Server handle server operations, client
connections, and game management.
The View Package includes ServerTUI and the ServerView interface, managing
server-side user interfaces and interactions.
Benefits of this Structure:
Separation of Concerns: Each package has a clear responsibility, separating different aspects
of the application, such as UI, game logic, client-server communication, and error handling.
7
Modularity and Scalability: The modular design allows for easy extension and modification
of specific components without affecting the entire system.
Code Reusability: Interfaces like Player and ClientProtocol facilitate code reuse and promote
adherence to contracts, enabling interchangeable implementations.
Maintainability: With a well-organized structure, it's easier to locate and update specific parts
of the codebase, enhancing maintainability and reducing the risk of introducing bugs.
Readability and Understandability: The logical grouping of classes and packages improves
code readability and understandability, making it easier for developers to navigate and
comprehend the codebase.
Overall, the MVC structure and package organization you've implemented provide a solid
foundation for developing and maintaining your Exploding Kittens game, offering clarity,
flexibility, and maintainability throughout the development lifecycle.
1.4. User Interface
This is the TUI for client side and server side:
When starting the server, you'll be greeted with a prompt asking for the server port.
Subsequently, when running the clients, you'll then be asked to enter the IP address and then
the server port. As soon as you're connected to the server, you'll be asked to enter your name.
8
After you have entered your name, the game starts with the command "SG", which displays
the list of players and the cards in your hand. During the game, you'll be accompanied by
prompts asking for various commands as required during your turn.
Meanwhile, on the server side, general messages will be displayed, e.g. about new players
joining the server, waiting for the game to start, or about whose turn it's and which cards are
currently being played.
The implemented chat on the client side:
The chat feature on the client side displays messages exchanged between clients alongside
the name of the individual who sent each message. They are different color to make it easier
to distinguish.
The winner message:
When someone wins the game, the server announces to all clients who the winner is.
For the local game Exploding Kittens:
9
When you run the game, you'll encounter a prompt requesting your preferred game mode
selection: 'm' for multiplayer, 'l' for local, and 'c' to play with a computer. Once you've chosen
the game mode, you'll be prompted to input the number of players and the names of each
participant. Following the game's initiation, it will display the number of cards that everyone
has in hand and the count of Exploding Kittens remaining in the deck.
The local game TUI:
During each turn, the game will prompt you with an inquiry: "Do you want to play a card?" If
you opt to play a card, you'll need to type 'y' and then provide the index of the card you wish
to play. This process continues iteratively throughout the game.
2.1 Unit Testing
10
The GameManagerNetworkTest class(for the client-server) contains several test methods
designed to validate the functionality of the GameManagerNetwork class, this is tested in
isolation, focusing specifically on the functionality of the GameManagerNetwork class and
its interaction with the Player(computer player and human player) and Card classes.
- Test Start Game (testStartGame):
This test method verifies that each player receives the correct number of cards (7 cards plus 1
defuse card) when the game starts.
It ensures that the game setup initializes player hands correctly, which is crucial for
maintaining game balance.
By testing the initial state of the game, we ensure that players have the necessary resources to
participate effectively.
- Test Play Card (testPlayCard):
This test method checks the functionality of playing a card from a player's hand.
It simulates a player playing a card and ensures that the card is correctly removed from the
player's hand.
Verifying that the game state is updated accurately after a card play is essential for
maintaining game integrity and consistency.
- Test Handle End Turn with Exploding Kittens
(testHandleEndTurnWithExplodingKittens):
This test method examines the behavior of handling the end of a turn when a player draws an
Exploding Kitten card.
It validates that the game responds appropriately by forcing the player to insert a defuse card
to defuse the Exploding Kitten.
- Test Play Turn with Computer Player (testPlayTurnWithComputerPlayer):
This test method focuses on the behavior of playing a turn when it's a computer player's turn.
It ensures that the game manager correctly invokes the computer player's turn logic and
updates the game state accordingly.
Testing interactions with computer players helps ensure that the game's AI behaves as
expected and contributes to a challenging and engaging gameplay experience.
11
Overall, these test methods provide comprehensive coverage of key aspects of the game
logic, including game setup, card playing mechanics, handling game events, and interacting
with computer player.
The HumanPlayerTest class is tested in isolation and contains several test methods aimed at
ensuring the correctness and functionality of the HumanPlayer class, which represents human
players in the Exploding Kittens game.
- Test Get Number Of Card (testGetNumberOfCard):
This test method verifies that the getNumberOfCard method correctly counts the number of
specific cards in the player's hand.
It tests the functionality to ensure that the player's internal counters are updated accurately
based on the cards present in the hand.
- Test Play Combo (testPlayCombo):
This test method examines the behavior of the playCombo method, which allows the player
to play a combo of specific cards from their hand.
It ensures that playing a combo correctly removes the specified cards from the player's hand.
- Test Give Card (testGiveCard):
This test method validates the functionality of the giveCard method, which allows the player
to give a random card from their hand.
It ensures that the given card is indeed present in the player's hand after it's given.
- Test Find Matching Card Type (testFindMatchingCardType):
This test method checks the findMatchingCardType method, which is responsible for
identifying a matching pair of cards in the player's hand.
It verifies that the method correctly identifies a matching pair and returns the appropriate card
category.
- Test Is Action Card Player (testIsActionCardPlayer):
This test method evaluates the isActionCardPlayer method, which determines whether a
given card is an action card.
12
It ensures that the method correctly identifies action cards and non-action cards based on their
card category.
- Test Has Card (testHasCard):
This test method validates the hasCard method, which checks if the player has a specific card
in their hand.
It tests the method's ability to correctly identify the presence or absence of a card in the
player's hand.
These test methods collectively provide comprehensive coverage of the HumanPlayer class,
ensuring that its methods behave as expected and maintain the desired game state.
The GameManagerTest class(for the local game) contains test methods aimed at ensuring the
correctness and functionality of the GameManager class, which manages the game logic in
the Exploding Kittens game. Below is a breakdown of the test methods and their
justifications:
- Test Exploding Card (testExplodingCard):
Justification: This test method verifies the behavior of the game manager when an exploding
card is encountered.
Scenario: It simulates a scenario where a player draws an exploding kitten and checks if the
game manager correctly handles the situation by removing players when they draw an
exploding kitten without a defuse card.
Test Objective: Ensure that the game manager correctly handles the removal of players when
they draw an exploding kitten without a defuse card.
- Test Start Game (testStartGame):
This test method checks the functionality of starting a game by the game manager and
ensures that each player receives the correct number of cards at the beginning of the game.
Ensure that the startGame method initializes the game state correctly
by distributing the correct number of cards to each player.
- Test Play Game (testPlayGame):
This test method evaluates the game manager's ability to play through a game session and end
with a winner.
- Test Objective: Ensure that the game manager can handle the game flow and
13
correctly identify the winner at the end of the game.
- Test Play Combo Action (testPlayComboAction):
This test method examines the game manager's ability to handle playing a combo action.It
verifies that when a player performs a combo action, such as playing multiple cards of the
same category, the game manager correctly executes the action by removing the cards from
the player's hand.
These test methods collectively provide comprehensive coverage of the GameManager class,
ensuring that its methods behave as expected and maintain the desired game flow and state.
By validating various aspects of the game manager's functionality, these tests contribute to
the reliability and correctness of the Exploding Kittens game implementation.
The DeckTest class contains test methods aimed at ensuring the correctness and functionality
of the Deck class, which represents the deck of cards in the Exploding Kittens game
- Test Deck Initialization (testDeckInitialization):
This test method verifies the initialization of the deck by checking its size after creation.
Ensure that the deck initializes with the correct size.
- Test Insert Exploding Card (testInsertExplodingCard):
This test method checks the insertion of an exploding card into the deck at a specific index.
- Test Defuse Card (testDefuseCard):
This test method ensures that every player has a Defuse card in their hand after the game
starts.
- Test Exploding Card Absence (testExplodingCard):
This test method confirms that no player has an exploding kitten card in their hand after the
game starts.
By validating various aspects of the deck's functionality, these tests contribute to the
reliability and correctness of the game implementation.
The ComputerPlayerTest class contains test methods aimed at ensuring the correctness and
functionality of the ComputerPlayer class
14
- Test Play Combo (testPlayCombo):
This test method verifies the ability of the computer player to play a combo of specific cards
from its hand.
- Test Give Card (testGiveCard):
This test method validates the functionality of the computer player giving a random card from
its hand.
Scenario: It adds multiple cards to the player's hand, requests a card to be given, and checks if
the given card is still in the hand.
- Test Find Matching Card Type (testFindMatchingCardType):
This test method checks the computer player's ability to find a matching pair of cards in its
hand.
- Test Is Action Card Player (testIsActionCardPlayer):
This test method verifies the computer player's ability to identify action cards.
These test methods collectively provide comprehensive coverage of the ComputerPlayer
class, ensuring that its methods behave as expected and maintain the desired functionality for
computer-controlled players in the Exploding Kittens game.
2.2 System Testing
Our system testing plan involved playing games extensively both with each other and with
the computer player to thoroughly evaluate the game's functionality and performance. We
intentionally introduced commands or incorrect movements to observe how the game handled
different scenarios so that we could identify and fix any potential problems or bugs.
We also solicited feedback from friends to determine their perception of the game and its
usability. Their insights helped us understand the user's perspective and provided valuable
suggestions to improve the overall game experience.
Through these testing activities, we wanted to ensure that the game worked smoothly,
responded effectively to user interactions and provided players with an enjoyable and
intuitive experience.
15
Academic Skills Chapter (Mihnea Ambrus)
4.1 Time Management and Procrastination Avoidance
Over the course of Weeks 2 to 4, I effectively executed my time management plan. In Week
2, I successfully completed programming exercises during practicals, allowing me to dedicate
substantial time to the design project and mathematics. Week 3 followed suit with early
completion of programming exercises, enabling an early start on the system design project,
which I completed by Friday. As I transitioned into Week 4, efficient handling of lab
exercises and system design tasks provided me with the opportunity to focus on test
preparation. Additionally, my project partner and I successfully submitted Milestone 1 for our
project on time. Overall, I am content with how I've navigated and balanced my academic
commitments during this period.
As I moved through the weeks, I learned to be flexible with my time management. If things
didn't go as planned, I adjusted my schedule to focus more on challenging tasks. I regularly
reviewed my progress and made changes to improve efficiency. This helped me overcome
setbacks and stay on track.
For the project, my partner and I kept things simple. We communicated well, set clear goals,
and stuck to deadlines. When issues popped up, we talked about them and found solutions
together. Using shared schedules and tools helped us work smoothly and manage our time
effectively. This teamwork approach made the project more manageable and successful.
4.2 Time Management and Procrastination Avoidance
Through the analysis of my Learning Journey in this module, I have identified both strengths
and weaknesses. I find that I can comprehend and implement logical structures efficiently.
However, I have recognized networking, especially in the context of the project, as a
weakness. I faced challenges understanding and implementing networking components. In
terms of academic skills, my time management has been effective, allowing me to complete
16
tasks on time. Recognizing strengths and weaknesses has been beneficial, and peer feedback
has provided valuable insights. The use of metacognition and self-regulated learning,
particularly during checkpoint meetings, helped me reflect on my progress. While I
appreciated the results, I believe I can improve by seeking additional resources and guidance
to strengthen my understanding of networking concepts in future projects
4.3 Checkpoint meetings
The checkpoint meetings with my mentor were crucial for my learning experience in this
course. Every two weeks, we engaged in a thoughtful review of my progress. I took the time
to assess my strengths and areas that needed improvement, following the metacognition
cycle. This process allowed me to reflect on my learning journey and set new goals for the
upcoming weeks. The feedback received from my mentor played an important role in this
self-assessment. Their insights provided a different perspective and highlighted aspects I
might have overlooked.
Academic Skills Chapter (Maia Souvannasouck)
4.1 Time Management and Procrastination Avoidance
In weeks 2, 3 and 4 of my course, I made an effort to manage my time and assignments
effectively. In week 2, my main goal was to complete programming and system design
assignments and delve into math topics. Although I felt overwhelmed, I managed to
accomplish most of my goals, relying on the lecturer's support and online resources to deepen
my understanding of Java and object-oriented programming. Week 3 presented me with
similar challenges, particularly in terms of balancing programming and system design tasks.
Although I was successful in the programming tasks, the system design projects proved to be
more difficult, resulting in some setbacks in achieving the planned goals. In week 4, although
I made considerable progress on the programming assignments and explored topics from the
previous weeks, I encountered further difficulties in the area of system design. Despite the
setbacks in completing all planned objectives, I remained optimistic and determined to refine
my skills and overcome the challenges in the coming weeks.
17
In the following weeks, I tried to prioritize my tasks and divide my working hours
accordingly. Initially, I managed to maintain this balance. During the vacation period,
however, I fell behind. When classes resumed, I found myself under a lot of stress due to the
upcoming exams and assignments. Despite the pressure, I worked hard and persevered and
eventually managed to catch up with my academic commitments.
During the project, my partner and I maintained excellent communication, meeting as
often as possible to enhance our collaborative efforts. We established clear goals and
whenever I faced challenges, my partner patiently explained and assisted me, enabling me to
overcome obstacles efficiently.
4.2 Time Management and Procrastination Avoidance
Through my learning journey, I've come to recognize both my weaknesses and my
strengths. I've discovered that I can be diligent and overcome procrastination when I'm highly
motivated, even if it hasn't always been easy. I've learned that forcing myself to grasp a
subject can lead to frustration; instead, motivation and composure are crucial to my success.
It was a challenge to understand the networking aspect of the project and my stress was
hindering productivity. However, the review meetings helped me to find strategies to increase
efficiency both in learning and in everyday life.
4.3 Checkpoint meetings
The checkpoint meetings with my mentor were really helpful in making me
understand exactly what problems I have in learning and what I should do from now on to be
more efficient and to be able to pass exams and assignments without to stress me very much.
18
Appendix
Image2&3&4: MVC application
19
20
21
22
