Course:CPSC312-2016-Project1-Battleships

Battleships

Authors: Vishav Kandola, Daniel Hsiao

What is the problem?

The main focus of the project is to create a Battleship game in Prolog that is playable. Battleship is two-player guessing game where the objective is to destroy the opponent's ships before your ships are destroyed. Ships are placed on a board by each player and are unmovable. However, unlike the traditional Battleship game, our game will be single-player focusing on destroying ships at unknown locations on a grid within a minimal number of turns.

What is the something extra?

Several aspects will be included to increase the complexity in implementing the game. Interactiveness between the game and the player will be included. For example, we plan to include the following if feasible (in increasing order of uncertainty):

• The game will ask the player to enter the initial condition of the game and display messages for every player action taken.
• Randomness will be included in the game to vary the ship positions at the start of the game to increase replayability of the game.
• The game will keep track of some statistics such as misses, hits, number of turns and report them to the player or provide a way to query from them after the game ends.

What did we learn from doing this?

(This should be written after you have done the work.) What is the bottom-line? Is logic programming suitable for (part-of) the task? Make sure you include the evidence for your claims.

We learned that Prolog is suitable for programming a logical inference game such as Battleships. We base this upon the initial prototype of the game being expressive enough to play a challenging enough game. We also familiarized our-self with a Shmorgous Board of various Prolog built-ins in order to increase the replayability and interactive-ness of the game. All in all; we met our initial objectives we set out to do.

The feature of randomization for the board was also suitable for Prolog, especially in a scenario where there were constraints needing to be placed, and randomly generated boards needed to be pruned on these constraints. A linearly recursive predicate "createShip" handled this logic.

We chose to represent the board by predicates that indicated facts about the board, instead of passing around the board state and other pieces of information. A benefit of this approach is that it's easier to write predicates that deal with facts instead of (say) a 2-dimensional representation of the board. However predicates that deal with conversion from the fact based approach to a 2-dimensional representation are still needed (see "printBoard").

In order to report statistics to the user however, we chose to use a tuple database that was updated as the game was played and cleared when a new game started. This had the effect of enforcing us to be aware of where backtracking was occurring and limiting us where we updated the database, which is indicative of the side effect permitting nature of Prolog which we took advantage of for the statistics piece.