Final Project Additional Information
Table of Contents
This is a pair programming assignment. If you are working in a pair, this means that you and your partner should be doing the entirety of this assignment side-by-side, on a single computer, where one person is "driving" and the other is "navigating." Set a timer to swap every 15 minutes. You can choose your favorite from this online timer page. Make sure your sound volume is audible, but not so loud to disturb the people around you.
If you are working in a pair, only one of you needs to submit your work via Moodle. That said, you should both have a copy of your work in case you want it someday, so make sure that both of you have copies of it; you can email it or use some other mechanism to transfer it.
We will use anonymous grading on Moodle, which means that the grader won't see your name until after the grading is done. This is an easy way to help add an extra element of fairness to the grading. Therefore, make sure your name doesn't appear on your actual submission. When you submit via Moodle, it will know you are. Thanks!
1 Previous games by other students that seemed to make good projects
- Bagels (note that you really want to do decent AI on this one, it's too simple a project without it)
- Battleship
- Boggle (checking if words are correct and AI is pretty hard, though)
- Chinese Checkers
- Clue (this was really complex)
- Connect Four
- Dots and Boxes
- Gin
- Go Fish
- Mancala
- Mastermind
- Othello
- Scrabble
- Set
- Parcheesi
- Wordsters
- Yacht / Yahtzee
- 3D Tic-Tac-Toe
2 Frequent misdirections
These are projects students seem to want to try that generally don't work out so well. If you're thinking about doing something from this list, you should explain in your design how you're going to avoid the pitfalls that others have run into.
- Poker: the AI is really hard and students get stuck trying to get something working.
- Blackjack: the AI on this is really dull; you just implement a set of rules you can look up anywhere. I'd rather you do something that you need to think harder about.
- Bowling / Football / other sports simulations: These usually turn out really hard for me to estimate correctness. I usually can't tell how deep the simulation is, vs just being a random action picker. I also usually can't tell how the user's choices affect the game.
- Some kind of adventure / role playing game: this nearly always devolves into a massive set of nested
ifstatements that don't really give students the opportunity to think about more interesting algorithms. This can be done right, but it's really easy to miss the mark. - Risk: getting the map is pretty hard, and tends to be all-consuming relative to the important parts of the project.