Battleboat Game Development Project, Study Guides, Projects, Research of Computer Science

A university project where students develop a two-player battleboat game. The project involves designing and implementing the game, group programming, creating multiple views of the common model, developing computer strategies, and revisiting all course material. The game rules are provided, and students must create a graphical user interface with options for new game, end game, exit, select view, how to play, and about. Students must also write at least two unique views of the game, one of which must use low-level event-handling, and implement at least two unique computer strategies.

Typology: Study Guides, Projects, Research

Pre 2010

Uploaded on 08/31/2009

koofers-user-jaw
koofers-user-jaw 🇺🇸

10 documents

1 / 4

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
C SC 335
By Martin Stepp
The final project this semester will be to implement a game called Battleboat. The
key concepts involved in this project are large project design and implementation,
group programming, multiple views of a common model, computer strategies / AI,
and a revisiting of all material from the course so far.
Game Rules:
Battleboat is a two-player game where each player tries to sink the other's fleet of ships. Each player has a grid
(usually 10 rows and 10 columns) of squares and five different boats that can occupy those squares: a Destroyer
(2 squares long), a Cruiser (3 squares long), a Submarine (3 squares), a Battleship (4 squares), and a Carrier (5
squares). Each player's grid and ships are hidden from view from the other player.
At the start of the game, each player places his/her ships on the board wherever he/she likes. After ships are
placed, the players begin taking turns firing shots at each other. A player fires a shot into a square on the
opponent's board and receives word if the shot was a Miss, a Hit, or a Sink. A shot is a Hit if it is fired into a
square that is occupied by a boat; it is a Sink if the boat is now entirely covered with Hits. The first player to
sink all of his/her opponent's boats wins the game.
More complete rules for a similar game can be found online at the following web site:
http://www.centralconnector.com/GAMES/battleship.html
GUI / Controller:
Your game must have a graphical user interface (GUI) sufficient to run and configure the game. The interface's
commands may be implemented any way you like: as buttons, menus, key presses, et cetera, or a mix, as long as
an average user can easily determine how to do them. You must have options in your GUI to perform all of the
following actions:
New Game, End Game, Exit, Select View, How to Play, About
When starting a New Game, the player should be able to select names for each player, as well as select
computer strategies for non-human players. When the user selects How to Play, he/she should see a window or
dialog showing the game rules and how to play your game. You may use a pre-existing HTML page with an
editor pane for this if you like. The About option should show your project name and the names / emails of
your group members, plus any additional information you like.
Views:
Your game must display a graphical view of its model on the screen.
You must write at least two unique views of your game. Only one
view needs to be visible at a time. However, the current view should
be selectable from your graphical user interface. Changing views
should not modify the state or logic of the game; the underlying model
must be independent of how it is being viewed.
pf3
pf4

Partial preview of the text

Download Battleboat Game Development Project and more Study Guides, Projects, Research Computer Science in PDF only on Docsity!

C SC 335

By Martin Stepp The final project this semester will be to implement a game called Battleboat. The key concepts involved in this project are large project design and implementation, group programming, multiple views of a common model, computer strategies / AI, and a revisiting of all material from the course so far.

Game Rules:

Battleboat is a two-player game where each player tries to sink the other's fleet of ships. Each player has a grid (usually 10 rows and 10 columns) of squares and five different boats that can occupy those squares: a Destroyer (2 squares long), a Cruiser (3 squares long), a Submarine (3 squares), a Battleship (4 squares), and a Carrier ( squares). Each player's grid and ships are hidden from view from the other player. At the start of the game, each player places his/her ships on the board wherever he/she likes. After ships are placed, the players begin taking turns firing shots at each other. A player fires a shot into a square on the opponent's board and receives word if the shot was a Miss, a Hit, or a Sink. A shot is a Hit if it is fired into a square that is occupied by a boat; it is a Sink if the boat is now entirely covered with Hits. The first player to sink all of his/her opponent's boats wins the game. More complete rules for a similar game can be found online at the following web site: http://www.centralconnector.com/GAMES/battleship.html

GUI / Controller:

Your game must have a graphical user interface (GUI) sufficient to run and configure the game. The interface's commands may be implemented any way you like: as buttons, menus, key presses, et cetera, or a mix, as long as an average user can easily determine how to do them. You must have options in your GUI to perform all of the following actions: New Game, End Game, Exit, Select View, How to Play, About When starting a New Game, the player should be able to select names for each player, as well as select computer strategies for non-human players. When the user selects How to Play, he/she should see a window or dialog showing the game rules and how to play your game. You may use a pre-existing HTML page with an editor pane for this if you like. The About option should show your project name and the names / emails of your group members, plus any additional information you like.

Views:

Your game must display a graphical view of its model on the screen. You must write at least two unique views of your game. Only one view needs to be visible at a time. However, the current view should be selectable from your graphical user interface. Changing views should not modify the state or logic of the game; the underlying model must be independent of how it is being viewed.

Elements that must be present in each view are:  the game boards for every player  the boats, if appropriate (for the human player -- you generally should not show the opponent's boats!)  all shots that have been fired on the boards, including whether each shot was a Hit, Miss, et cetera  each player's name  an indication of whose turn it is  reasonable response to important game events (new game, game over, etc. -- some notification) No more than one view may be a text view. That is, only one view may just draw letters or Strings on the screen to represent the objects of the game, or be composed entirely of pre-existing Java graphical components. The view pictured at right would be considered a text view. All other views must draw shapes, images, and other more genuinely graphical entities (generally by writing custom panel classes and painting on them appropriately). The view should be changeable at any time during the game. Even in the middle of playing, the user should be able to use the GUI to change views, and the game state should be kept the same. At least one view should use low-level event-handling. This means that at least one of your views should have the user interact with the game by listening for mouse and/or keyboard events. Other methods of input are action listeners and other listeners attached to Java GUI components. To ensure that your views are appropriate and unique, please see your grader.

Strategies:

The computer players in the game must play according to swappable strategies. These strategies should be implemented as strategy objects attached to the players. When it is a computer player's turn to move, he/she consults his/her strategy object and asks it for what move it would like to make. Different computer players must be able to use different strategy objects. You must implement at least two unique computer strategies in your project_._ Elements of a computer strategy for this game are:  ability to position its boats at the start of the game  choosing where to fire when it is the player's turn Only one of your strategies may be primarily "random" or "stupid". That is, you may write a random strategy class that places its boats randomly and always fires at an arbitrary square, regardless of what is going on in the game, but you may not have such randomness in any other strategy classes. Other strategies may have some element of randomness to them (for example, to break ties between equally desirable moves), but may not be primarily random in nature. No strategy may make invalid decisions. That is, no strategy may place boats so that they overlap or fall off the board, no strategy may fire shots into squares that have already been shot or squares off the board, et cetera. The strategies must play within the rules of the game. At least one strategy must be "smart." That is, it must play the game intelligently by placing its boats and firing its shots in places that make it more likely to win the game. Some elements of a "smart" strategy could include, but are not limited to:  placing the boats in ways to avoid their detection (spreading them out, putting them in odd places)

Extra Features (20pts)

Some of the points on this project will come from adding additional features not listed in the above specifications. The following are examples of valid extra features you may implement in your game. All are worth 5 points maximum except networking, which is worth the entire 20 points.  Additional unique view  Additional smarter strategy  Load/save a game in progress (no Applet)  Run the game as an Applet (no persistence)  Additional model rules (e.g. "Salvo" game)  Undo/redo feature  Sound support  Network play with other human players (20pts) You may come up with your own additional features and suggest them to your program managesr for approval. Unapproved extra features will be worth no points. The point value received for extra features will be proportional to the difficulty.