1. Introduction

Eventhough the game we call Battleship isn't very complicated, this project certainly is. It covers almost every topic presented in class, and many more. You will have to do a lot of reading and learning on your own, but don't worry. Everything important will be introduced in class or in lab, and you will often simply end up elaborating on it. And don't forget, the resources at your disposal are limitless.

One important thing to remember is that if you pay attention in class, do all the labs yourself, and start the project early on, you will successfully complete it and get a good grade! So, don't procrastinate... No, we really mean it!

1.1 About the Game

Battleship is based on a game played by radio operators during WW2, designed as a way to test radio transmissions, and bypass Japanese intelligence. Battleship is played between two people in a 'virtual places' environment.

The game is played on two grid boards. Each player has 5 ships to place on their boards. These ships are:

• Aircarft Carrier (covers 5 squares on the grid)
• Battleship (covers 4 squares on the grid)
• Cruiser (covers 3 squares on the grid)
• Destroyer (covers 2 squares on the grid)
• Submarine (covers 1 squares on the grid)

The goal of the game is to sink all of opponent's ships. Battleship is a turn-based game, and during each turn you or your opponent gets to shoot. Strategy and some luck must be combined to be the first to sink all 5 opponent's ships and win the game.

Before the game begins, both players place their battleships on the battlefield. Once both players are ready, i.e. placed all 5 ships, the game begins. The player who initiated the game (in our case, connected first) gets to play, or shoot, first.

If you'd like to play a nice, Flash-based Battleship game right now against a computer opponent and familiarize yourself with how it works, click here.

1.2 Project Objectives

• Asynchronous, message-driven programming
• Win32 API programming
• Synchronous network programming with sockets (WinSock 2.0) and HTTP commands
• Threaded execution within Win32 applications (creating and destroying threads)
• Child windows and child window controls
• Menus, dialog boxes, icons, and other resources (using the VS Resource Editor)
• Scroll bars, system timers, and fonts
• Handling mouse and keyboard events
• Large project development within a small team

1.3 Team Information

You can either work on this project alone or in a pair (Pair is two. Not three. Two.) Make sure either both your names are mentioned in the About dialog box if you decide to work in a pair. You are more than welcome to get help from your friends and classmates, but, believe us, don't copy. Your TA will ask you a lot of questions about the project when you're demonstrating it. The fact that it runs only earns you a small percentage of the points, your explanation earns the rest.

1.4 Deadlines

The project will be submitted in two increments. The requirements for both increments are described later on in this document.

The first increment has to be demonstrated to your TA before Friday, November 15th. The second increment, which is the final version of your project, has to be demonstrated before Friday, December 6th. Don't miss the deadlines! You'll be allowed to submit increment 1 late, but for late credit. The deadline for increment 2, however, is final.

The following needs to be completed for increment 1:

• All windows (including child windows) need to be created and displayed.
• The menubar must be present, and the application should be capturing messages it generates.
• The log window must be fully functional, including the scroll bar.
• The battlefield windows need to be drawn out properly.
• The application must catch WM_LBUTTONDOWN messages and determine the position the mouse clicked. No further action needs to be taken.
• The timer window must be operational.