Wednesday, November 11th — 11:59pm
This project is designed to give you some hands on experience with…
- Using Xcode & Interface Builder
- Declaring and wiring outlets and actions
- Testing applications in the iPhone Simulator
- Utilizing Core Graphics to generate custom UIViews
- Handling touch-based events and updating graphics accordingly
For this assignment you will be writing a basic Four-in-a-Row app. Your implementation will be a 2-player version of the game where the iPhone/iPod touch could be passed back and forth between two players. This saves you the overhead of implementing an AI to play against.
Your application needn’t look identical to the one shown in the description, but must it contain the following elements…
- A toolbar with a button that allows the user to start a new game
- A large game board that must be rendered using Core Graphics and contain the following elements:
- The main game board section that has holes in it to see the dropped piece (yellow in my screen shots)
- Legs on each side that protrude below the bottom of the main board section (blue in my screen shots)
- Pieces visible through the board as they are dropped into a column (red and black in my screen shots)
- The piece about to be dropped should be rendered above the currently selected column (red and black in my screen shots)
- A “status” label that informs users of whose turn it is and alerts users to wins/losses/ties
- Running totals for:
- Red Wins
- Black Wins
- Customize the game pieces
- Add in some animation (i.e. show the piece dropping to the correct slot)
- Try out alternate color combinations — just don’t make my eyes bleed
- Feel free to play with the layout and style of elements — just be sure that things are neatly aligned and that there is at least some justifiable method to your madness
- Add your own images
- Correctness of application
- Appearance of application
- Adherence to Objective-C and iPhone coding conventions
- Neatly formatted and indented code
- Well documented header files
- Absence of significant performance issues
- Absence of memory leaks
Main App Behavior
When your app initially loads it should look similar to the screen shown below. When the app is launched a game should automatically start and whose turn it is should be shown in the status area.
The user starts the column selection process by pressing their finger down over a column. When the finger is pressed down (and not yet released) the player’s piece should appear centered above the column their finger is over. The user should be able to drag their finger left and right, and as they do so, the marker should switch columns as needed. You’ll need to detect where the user has their finger and draw accordingly (in my implementation the finger can appear anywhere “in” that column for the full height of the UIView). A finger press is shown below.
Only when the user lifts their finger should the selection be finalized and the piece dropped to the bottom-most free row as shown in the screen shot below. Note that the status has also been updated to reflect black’s turn.
The screen shot below shows the finger press down for the black player. Notice that the piece is now black at the top when the user presses their finger down.
Again, only when the user’s finger is released should the current column be selected as shown below. Notice that the status is once again updated to reflect the red player’s turn.
As users drop pieces into the game board your app should check to see if a user has one by getting four-in-a-row on the horizontal, vertical or either diagonal. If a four-in-a-row is detected, your app should notify the winner in the status area. Additionally, your app should draw a line on the board indicating the four-in-a-row as shown below.
If the game board is not currently in play (someone won or there was a tie) and the user presses the “New Game” button, the app should clear the board and alternate user turns. Below we see the result of pressing the button — it is now Black’s turn.
If the game is not over and the user presses the “New Game” button, an action sheet should should pop-up to confirm that the user really wants to abort the current game as shown in the screen shot below. If the user accepts, the board should be reset. If they decline, then game play should continue uninterrupted.
Your app should be smart enough to not show the user’s piece above the board if the column is full (or if the game is over). For example, if the user presses their finger down in the column immediately left of center the piece should appear…
…then if they drag to the right, the piece should disappear from the column left of center, and since the center column is full no piece should appear above the center column…
…but if they continue to drag to the right, once they clear the full column, the marker should reappear as shown below…
If the board gets completely full without a win, an appropriate status message should be updated. Pressing over any column should have no effect.
There are no persistence requirements for this assignment.
As usual, the first thing I’d probably do is to print out the initial screen and identify outlets, ivars, action methods, etc. You can probably build out the initial UI pretty quickly — less the custom UIView being drawn to by CoreGraphics.
To tackle the UIView that’s rendering the game board I’d recommend starting by sketching out on a piece of paper the overall outline of the board and position of notable items (i.e. legs, main board, position of holes & location of hover pieces). You really need to plan out the dimensions of all of these elements before digging in. I’d recommend making this UIView as large as you can in IB and jotting down the dimensions so you know what your constraints are.
Once you know the positions of the items you will be drawing, I’d move into actually building out and rendering those items. It probably makes sense to start with the 2 legs and main board. Once you have that positioned appropriately, I’d them move onto painting the holes in the board. You’ll want to figure out how to do this using loops — you really don’t want to specify the coordinates of all 42 holes.
After you have the static board drawn, I’d then move onto capturing the finger events and simply logging which column on the board you’re over. Once you know you have that correct, you can move onto actually trying to render the piece in real time. Next, I’d probably write the code to actually drop a piece into the correct position when the finger is released.
Once you have that done, it’s a matter of implementing the game logic — alternating turns, checking for wins, updating UI labels, etc. You’ll want to handle suppressing the piece if it shouldn’t be displayed. You’ll also need to wire in the “New Game” button and add the action sheet.
Lastly, don’t forget that you need to draw a line through the four-in-a-row. Think about what information you need to draw this line and where/when you have it.
The following items are provided as thoughts as to how you might extend or improve the project beyond the basic requirements. You are not required to implement any of these.
Your projects will be graded on the following criteria:
Like the previous assignment, you are required to submit a zip file of your project directory. Be sure to manually remove the build directory before zipping things up.
To submit the assignment, open up a terminal, navigate to your zip file then issue the command:
submit cs491i assignment7 Assignment7.zip
If developing on your own Mac, you’ll need to transfer the file into your GL account (via SCP), then SSH into GL and issue the submit command.