These instructions will get you a copy of the project up and running on your local machine.

1.) Download this repo via the Clone or download button or clone it via the git CLI:

git clone https://github.com/krishchow/Null-Battleship.git

2.) Once the folder is downloaded and opened ensure the requirements are installed via pip:

pip install -r requirements.txt

3.) Start the game by running driver.py, either manually in a python interpreter or via python CLI:

python driver.py

A quick narrated playthrough of the game:

The game is played using keyboard inputs.

[0-7]       Number range for board coordinates [Row, Column]

[1-5]       Number range for the game's ships

[U,D,L,R]   Letter range for choosing ship's direction [Up, Down, Left, Right]

Important: Inputs must be separated by spaces.

The game has 5 different ships, each with their own abilities. Players spend their credits on ships of their choosing.

• Python 3 - Language
• Pygame - Game Library

We have broken our code up into several key folders and classes. This is captured in the diagram below, which shows we organized the code.

Our model folder contains all code related the core data involved with gameplay. This means the following classes:

• Board - The Board is the primary representation of the game's current state, and it mainly contains pointers to 64 Tile objects, each of which maintains the current state of an individual tile.
• Ship - The Ship abstract class and it's implementations, each of which represents one of the possible ships a player might place on their board.
• Tile - The Tile class maintains all information about a specific tile, and also contains a pointer to the Ship object currently on that Tile (if there is one).

These classes interact with each other through a variety of functions defined in the Board class. The Board class is responsible for maintaining the overall state of a player's Board and allowing for standard operations on that board, such as placing a ship, making an attack or scout on that ship and reporting if all ships are sunk.

The view code is all captured in the view, view_support and stages files. There are several key classes, such as Stage, GameView, Clickable, ShipDisplay and Button.

• GameView - This is the central class responsible for running the view and performing the core parsing
• Stage - The Stage abstract class is the class responsible for rendering and handling input from any stage in the game
• ShipDisplay - The ShipDisplay is used to render the Ship sprites in the Ship Selection Stage.
• Label - The Label is a common class used in various stages, which renders some dynamic text
• Image - The Image is also a common class used for rendering an Image at some coordinates
• Button - The Button is a Clickable object which calls a handler function when it is clicked.

The primary interaction is between the Controller and the Stages. At a high level, the stages can be dynamically swaped when going between different game states. This allows for a cleaner and more extensible page structure.

Each stage encapsulates one specific game function, and calls on the appropriate helper functions where required. Options like background color, image sizes, button locations and display text can all be found in the appropiate stage for the game state.

The driver is the file which must be executed to run this application. The Main class is responsible for coordinating the view and the model. It also provides critical parsing functionality which is used by the various stages. The controller also checks if win conditions are met and handles Ship building.

The first step to contribute to this project would be to clone the GitHub repository, and install the prerequisite software.

In order to contribute to this project, we encourage you to first read the existing code base. This should provide with an understanding of the various code components and logic behind the model. From here, you can begin working on your additional features, while making use of the existing helper functions. Please ensure that all new code conforms to the flake8 style standard.

After finishing your code features, please create a pull request on GitHub. You can find a great guide for how to create a Pull Request here.

Pirateship is a user-friendly interactive game that the public can extend in order to add features and personalize game aspects which will enhance the experience of a childhood favourite playdown. Don’t know where to start? The following are examples that an individual can incorporate in order to extend the game:

Obstacles that increase the difficulty of the board configuration when players select the location of their ship on the map. For example, particular areas within the board boundaries can be set as island or rock objects.

Different and personalized themed maps, ships and game graphics. For example, as opposed to the traditional battleship and Pirateship, one can choose to extend the game to play an aircraft version of the game, “AirShip”.

Minigames and other game modes. For example, a survival game mode can be implemented where you and your opponent only possess one ship and must play until one player kills the other players sole ship.

How to extend Pirateship (Instructions):

--> In order to add obstacles to an extended version of Pirateship, follow the instructions below:

1) In order to add an obstacle, such as an island on the board during gameplay, an individual will need to extend the model folder of the game, since the objects of the game are present here. 

2) The next step would be to implement an Island class, which includes the initialization of attributes consisting of the length, name, health, etc. of the island object. 

3) Each object needs an image, for which the code needs to be rendered within the Image class under the utilities folder. 

4) Once the obstacle class is executed and the image is established, the BotSelectionPage class needs to be extended, in order for the Island obstacle to be present when a user is selecting the pieces to place on their respective board.

5) Lastly, the GameplayPage class needs to be improved in order to have the Island obstacle present on the board screen while the game is being played.  

Get innovative and add other features, use your creativity, and extend the game!

• Krish Chowdhary - I had a multi-faceted role in the team, and as a result, my code contributions can be found throughout the repository. Some of the key features that I worked on included writing the majority of the individual game stages, the Main class, the Board and the Tile classes. My work on the Board and Tile also involved designing how we wanted to model the Battleship game, and this initial planning stage was critical for the success of the game itself. The Main class involved bringing together all the different application components, and integrating them through a series of helper functions. These provided an easy API and made modifying and improving the code fairly straight forward. For the README, I worked on the “Code Overview and Design” section and one part of the “Contributing” section. I chose to work on the former since I had led to the discussion on the original design of the application, this meant that I had a deep understanding of how all the classes interacted with each other. For the latter, since I have some experience with open-source projects, I chose to write up a small guide to teach people how to contribute to the project.

• Sabeeh Ashraf - Throughout the journey of this project, I played an assistive and open-minded role. I worked to establish and code the credit system that is associated with the ships, particularly, the credits and types of available to each ship object (supported by Krish). Having past experience with pygame and being comfortable with graphics, I worked on the graphics for the ship objects. As per the README, my contributions can be witnessed through the “Extending Pirateship” portion. Within this section, I outlined potential out-of-scope features for individuals that may struggle to extend and personalize the game for themselves. I also provided an example of how to implement out-of-scope features. Lastly, I refined and edited the README document, checking for grammatical and spelling errors, and improved the document’s format in order to appeal to readers. Such tasks were assigned to me as I worked on out-of-scope features for our game, and displayed strong collaborative when refining our project plan.

• Jaden Banson - After originally drafting the high-level UML diagram for our view controller-based model. My contributions to the project mostly involved prototyping components and logic for integration. More specifically I was largely responsible for creating the board & map components. The creation of the board largely relied on my creation of a matrix to store player ship placements and movements. The creation of the map relied on a logically similar matrix to store and map player hits/misses on enemy ships. In addition to this, I was also responsible for writing the installation guide of this README. After these two primary contributions, I was also responsible for helping other team members with other miscellaneous code-base maintenance and development such as ensuring various methods and classes follow our object-oriented model, helping team members work through understanding high-level logic and operational issues (ie. version control & environment setup, etc).

• Zeina Adi - In terms of the README, I embedded our "demo" for our game, filmed it and did the voice over and edited the video. In terms of contribution to the code, I completed methods and writing the module view. Also, I was responsible for the input validation by user, sending error messages sent to the console. Finally, my role was to ensure text fields that asked for user input where transitioning into the game while runtime. I wrote the method judge that determines winner and loser conditions. Finally, I wrote and completed code for the Transition Stages.

• Kevin Borja - My contributions to the game were mostly towards working on the AI player and the AI vs Player game mode. This involved creating methods for the AI player to make ship selections, place ships, and attack the other player. One of the things I prioritized was ensuring that there was as little duplicate code as possible. After finishing the AI class, I worked on creating the AI vs Player game mode. For the README, I wrote about the game controls and its features. I listed what inputs the game accepted, and I put the different ships into a table, showing their names, costs, and abilities.

See also the list of contributors who participated in this project.

This project is licensed under the MIT License - see the LICENSE.md file for details