V22.0201 Machine Organization I
GAME PROGRAM - Final Semester Project
Due: Monday, May 4th (Last Day of Class)
[Note: NYU Computer Science Demo Day is Wednesday, May 6th]
The project is to write a game playing program. It
must be written in Assembler. It
text or video graphics. Many of your basic needs (random number
generator, timer) will be provided. We also give examples of mouse and sound
The type of games you can program is really up to your imagination.
What we would like to see in your games: interactivity, use of computer
graphics and some real-time elements (i.e., the player need to respond within
short time span). Hence it is unlikely that we will approve a project to build
a paint program or a screen saver! But check with me first.
We will grade you favorably if you impress us with something in your game.
So do not be shy to tell us of any nice features you have!
- Due no later than Wednesday, April 8th
You need to submit a TYPED proposal for your project. Your proposal must be
typed, proof read, spell-checked, etc. Bascially, it should look like a professional
proposal that would be given to a potential investor for your game project.
What is needed in your proposal:
- The length of your proposal should be about one type-written page (when
- Your Name and Section
- Title of project
- User level description of the game:
- What does the user see on the screen?
- What is the objective of the game?
- How does the user play? (buttons? keyboard?)
- What is the motif of the game? Theme? Colors?
- IMPLEMENTATION PLAN:
- What video mode will you use? (Why?)
- What technical tools do you need? (set up interrupt vectors, need random
number generator, need mouse, need sound, etc). You may need to read up
chapters 12,15 and 16.
- What user friendly features will you implement? (online help, ability
to set level of game, etc)
- Divide the effort into two parts: ``basic features'' of the game (that
you know you can finish in time), and ``advanced features'' (if time permits).
Be realistic even about ``advanced features''.
- GRAPH PAPER LAYOUT of all principal screens of your program (in 80 x 25
if text mode)
Your project should be realistic for our time frame.
It is STRONGLY RECOMMENDED THAT you may want to only implement the
basic features of your game before trying to
implement advanced features (see proposal above).
Try to allocate the last few days of the project
to debugging, commenting and documentation.
It is silly to work so hard on the programming part
but then neglect this simple part which is easy to satisfy,
and which carries a significant part of the grade.
IF YOU HAVE A GREAT, GREAT GAME AND WISH IT TO BE CONSIDERED FOR
INCLUSION IN THE CS DEMO DAY (Wed, May 6th), WE WILL PROVIDE TIMES ON MONDAY,
MAY 4TH FOR YOU TO DEMONSTRATE YOUR GAME TO THE CLASS.
WHAT TO SUBMIT TO THE GRADER on Monday May 4th
ITEM 1: REPORT
This item is a SINGLE document that is in TEXT format.
PROPER ENGLISH. Please take pride in what you write -- we want to emphasize
that writing well is an important part of your education. Make sure that you
write in English! For instance, each English sentence has a verb, not two and
not zero, and ends in a full stop (I have seen "sentences" that violate
such basic rules).
The document must contain the following sections:
No section or part may be omitted. For instance, if you have nothing to say in
Subsection B.1, then insert the sentence "Subsection B.1 is not applicable" (for
- COVER PAGE [-10pts]
(a) the course identification (including semester, year, instructor),
(b) name of project,
(c) Your Name
(d) Your ID
(e) Your email address (must have)
- SECTION A: CONTENTS PAGE [5pts]
(a) A table of contents of document.
(b) A list of all the files your are emailing (Consider ZIPPING them)
(c) Name of program modules
(d) Full credits to code or help obtained from elsewhere. You must specify
the source of any copied code, and tell us where is the original code in your
diskette. If this is all original code, state the following "THIS IS ALL ORIGINAL
(e) NOTHING ELSE.
- SECTION B: PROJECT OVERVIEW [10 pts]
B.1. Introduction: this is up to you.
B.2. The object of the game: this can be modified from your proposal.
B.3. The user view of the game: this can be modified from your proposal.
B.4. Highlight any interesting or special achievements.
- SECTION C: USER INSTRUCTIONS [10 pts]
C.1. How to install game (including requirements).
C.2. How to execute your program and play game. Include instructions for quick
EXIT from the game (typing ESCAPE, for instance).
C.3. Any features or hints for users to know about. Tell the user of possible
- SECTION D: TECHNICAL PORTION [10 pts]
D.1. High-level technical description of your project (1-5 pages). What kind
of graphics, sound, mouse or other routines. If you have done something nice,
this is the place to tell me! Here are some things of interest to us:
D.2. Summary of the different assembly modules: how they are organized and
related to each other. What are the key functions in each module.
- which graphics mode and any special graphic effects,
- music and sound effects,
- mouse programming,
- interrupt programming,
- use of randomness,
- use of the timer or other ports,
- keyboard programming,
- recursive procedures,
- memory management (chap.14, including .com),
- SECTION E: CONCLUSION [5 pts]
Describe suggestions for future work (if had time, say). Give suggestions
about how you might do things differently (a future student in this class
may be able to benefit from your experience). Include any interesting experience
while doing this.
- APPENDIX I: ORIGINAL PROPOSAL [2 pts]
Attache any approved modifications as well.
- APPENDIX II: ORIGINAL SOURCES [-100 pts]
Copy of any programs that are not your own, that you have used PARTS of or
modified for your project. Include information on your source (e.g., ftp site
where you downloaded the code). You do not need to include any programs taken
from our text book or which are provided by me.
ITEM 2: THE PROGRAM FILES
- Make certain that your name and identifying information is at the TOP of
your program code
- SUGGESTED FINAL CHECK: try to assemble your game and play the game using
the files which you hand in. Common mistakes include: (a) some crucial
files are missing, (b) you hand in the test version of a game, (c) you hand
in a debugging version of your asm.bat file.
- Consider ZIPPING your files together if you have more than one.
- The name of your program should be your last name and your first initial
- but limited to 8 characters. So, if your name is John Smith, your file would
be submitted as:
Besides the points already allocated for the above
items, we allocate the following points:
- If your game works properly, and implements all the basic features in
your proposal, you automatically get 100 points. If it works only partially,
get parts of 100 points. You get 0 points if there are assembly or compiler
errors. In view of this, we suggest that you take our suggestion to initially
effort on the ``basic game''.
- Online documentation [20 pts]: what we mean is that when we execute your
program, we will get an initial introduction to your game (its name, its
and how to play it). This can be as simple as showing a page of instructions
on the screen at the beginning of the game.
- We allocate up to 30 points for additional game features beyond your basic
game. Be sure to tell us about them!
- We allocate up to 20 points for making the game more user friendly. For
- You allow it to have a quick but graceful exit from the game (without
having to power down!). Or, one can get out from a long musical preliminary
(which is nice but...).
- You create several levels of playing ability.
- You ask if the player wants to play the game again, before quitting.
- You restore the original video mode after quitting the game.
- Comments and Inline documentation within the files [25 pts]. We will look
for overall description of the modules, the procedures that you have written
and how they call each other, etc. We normally do not read your code --
but based on your high level descriptions, we may poke inside your code...
- Projects of great imagination can be allocated up to an additional 75 points.
- Please be aware that your game will be used for my educational goals in
future courses. E.g., I will use it for demonstrations and possibly put the
code out for future students to modify and improve.
- Instructions are strict: It is hard to believe, but I have had students
who do not submit proposals. At the last moment they hand me a program.
This guarantees an automatic 0 for the project.
- Code re-use: It should be clear that we encourage you to reuse code
you find elsewhere, provided you do something new and creative with it.
Here are some caveats:
First, you should NOT take over a major piece of code, do some minor changes
to it, and claim it is your own. This is very serious plagiarism and
a university disciplinary problem.
Second, you should credit the author of any code that you modify, and give
a source for the code.
Thirdly, never use a piece of code without fully understanding it yourself.
- Debugging: You will need to do debugging more than ever. Test each
procedure before you proceed to writing the next one. It should be easy to
do this by writing a small main program (the book has many such examples).
Go into the debugger to see what your procedure is doing. Keep these test
main programs around, in case you want to modify your procedures later!
GOOD LUCK and HAVE FUN with this project!