V22.0201 Machine Organization I
Spring 2009

GAME PROGRAM - Final Semester Project
Due: Monday, May 4th (Last Day of Class)
[Note: NYU Computer Science Demo Day is Wednesday, May 6th]


INTRODUCTION

The project is to write a game playing program. It must be written in Assembler. It requires significant use of text or video graphics. Many of your basic needs (random number generator, timer) will be provided. We also give examples of mouse and sound routines. 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 a reasonably 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!

PROPOSAL - 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:

  1. The length of your proposal should be about one type-written page (when printed).
  2. Your Name and Section
  3. Title of project
  4. User level description of the game:
    1. What does the user see on the screen?
    2. What is the objective of the game?
    3. How does the user play? (buttons? keyboard?)
    4. What is the motif of the game? Theme? Colors?
  5. IMPLEMENTATION PLAN:
    1. What video mode will you use? (Why?)
    2. 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.
    3. What user friendly features will you implement? (online help, ability to set level of game, etc)
    4. 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''.
  6. GRAPH PAPER LAYOUT of all principal screens of your program (in 80 x 25 if text mode)

GENERAL PLANNING

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:

  1. COVER PAGE [-10pts]
    This contains
    (a) the course identification (including semester, year, instructor),
    (b) name of project,
    (c) Your Name
    (d) Your ID
    (e) Your email address (must have)
  2. 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 CODE".
    (e) NOTHING ELSE.
  3. 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.
  4. 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 problems here.
  5. 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.
  6. 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.
  7. APPENDIX I: ORIGINAL PROPOSAL [2 pts]
    Attache any approved modifications as well.
  8. 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.
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 instance).

ITEM 2: THE PROGRAM FILES

  1. Make certain that your name and identifying information is at the TOP of your program code
  2. 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.
  3. Consider ZIPPING your files together if you have more than one.
  4. 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:
		SMITHJ.ASM

GRADING

Besides the points already allocated for the above items, we allocate the following points:
  1. If your game works properly, and implements all the basic features in your proposal, you automatically get 100 points. If it works only partially, you 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 focus your effort on the ``basic game''.
  2. 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 objectives, 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.
  3. We allocate up to 30 points for additional game features beyond your basic game. Be sure to tell us about them!
  4. We allocate up to 20 points for making the game more user friendly. For example:
  5. 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... etc.
  6. Projects of great imagination can be allocated up to an additional 75 points.

NOTES

  1. 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.
  2. 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.
  3. 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.
  4. 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!