head	1.1;
access;
symbols;
locks
	yap:1.1; strict;
comment	@# @;


1.1
date	97.11.12.23.45.54;	author yap;	state Exp;
branches;
next	;


desc
@@


1.1
log
@Initial revision
@
text
@<html>
<title>
	FINAL PROJECT:
	V22.0201.002, Machine Org I,
	Fall 1997,
	Chee Yap
</title>
<body bgcolor=fafafa>

<center>
        <h3><font color=aa0000>
	Fall 1997, Professor Yap<br>
        V22.0201.002, Machine Organization I
        </font> </h3>
        <h2><font color=aa00ff>
        FINAL PROJECT
	<br>
	<b> Due</b>: Wed December 10, 1997 (Last Class)
        </font>
        </h2>
</center>
<hr>

<h3><font color=aa0000>
INTRODUCTION
</font></h3>

The project is to write a game playing program.
It requires significant use of interrupts and
text or video graphics (based on material in
chapters 12, 15 and 16 of the text book).
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.
<p>
This year, I plan to make it easier for people
to produce a substantial game without having to
begin from scratch.  I will provide you with several
games (from previous classes), and you are to
improve them in significant ways.  Our grading 
will (TRY) not discriminate between whether you take
this route or build a game from scratch.  There are
pluses and minuses, of course, which you can weigh.
This will be posted by the end of this week.
<p>
What I 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 I will approve a
project to build a paint program or
a screen saver!  But check with me first. 
<p>
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! 
<p>
YOU MUST KEEP THIS DOCUMENT WITH YOU THROUGHOUT THIS PROJECT
FOR REFERENCE.  WHEN IN DOUBT, ASK.

<h3><font color=aa0000>
PROJECT TEAM
</font></h3>

This project is to be accomplished by
a team of 2 or 3 students.  As I said, there are
tradeoffs between having 3 (less work per person
but perhaps ability to tackle a bigger project)
or 2 (less problems of coordination and personality conflicts).
To be successful, please be
willing to be flexible and ``go the extra mile'' for your
partner (you never know when you might need your
partner's goodwill later).  Remember: even
if you have difficulties with each other, it may be
to your advantage to cooperate.
If there are problems you cannot resolve, please
inform me and I will intervene.

<h3><font color=aa0000>
PROPOSAL
</font></h3>

You need to submit a proposal for your project.
The proposal can be submitted any time before
next WEDNESDAY (November 19).  You must submit
the proposal by email.  What is needed in  your proposal:
	<ol>
	<li> The length of your proposal should be about
	 	one type-written page (when printed).
	<li> Names of team members (names and email)
	<li> Title of project
	<li> User level description of the game:
		<ol>
		<li> What does the user see on the screen?
		<li> What is the objective of the game?
		<li> How does the user play?  (buttons? keyboard?)
		</ol>
	<li> IMPLEMENTATION PLAN:
		<ol>
		<li> What video mode will you use? (Why?)
		<li> 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.
		<li> What user friendly features will you
			implement?
			(online help,
			ability to set level of game,
			etc)
		<li> 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''.
		</ol>
	</ol>
Note that I intend to approve your proposal 
almost instantly by email, unless I
find some problems.  If your project starts to
deviate from your proposal, you need to obtain
my permission and perhaps resubmit a new proposal.

<h3><font color=aa0000>
GENERAL PLANNING
</font></h3>

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).
<p>
Try to allocate the last few days of the project
to debugging, commenting and documentation.
<b>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.
</b>
<p>
We suggest that you each delay any other ``optional''
activities for at least the last 2 weeks of this project. 
<p>
POINT ALLOCATION: Our goal is to make this
grading process as predictable as possible.
We will, as usual allocate a certain number
of points to certain items.  BUT some items are allocated
<b>negative points</b>.  E.g., the COVER PAGE
of your report carries negative 20 points.
This means that if you fail to provide an adequate
cover page, up to 20 points are subtracted.
But no positive points are allocated for the cover page. 
So your aim is to get 0 points for your cover page.

<h3><font color=aa0000>
TO BE HANDED IN
</font></h3>

Hand in the following 2 items in an envelop (sealed)
with the following information:
	<pre>
	FINAL PROJECT, V22.0201.003, Yap
	Your project name.
	Your team names
	</pre>
It is your responsibility to keep extra copies of what you hand in,
and we suggest you put the envelop under my door rather
than in the mail box (we had one lossage in hw3).

<p>
<b>ITEM 1: REPORT</b>
<p>
This item is a SINGLE document that is placed between
proper covers [-5pts].
E.g., to get a SINGLE document,
you must staple everything together, or use a binder clip.
<p>
PROPER ENGLISH [-20pts].
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).
NOTE: Sorry we have to say this.
The grader reported some sloppy writing in your hw2
when you had to write some sentences.
<p>
The document must contain the following sections:

<OL>
<li>	COVER PAGE [-20pts]<br>
	This contains <br>
	(a) the course identification
	(including semester, year, instructor),
	<br>
	(b) name of project,
	<br>
	(c) Team Member Names,
	<br>
	(d) their ID's,
	<br>
	(e) email address,
	<br>
	(f) phones (optional).
	<br>
	And NOTHING ELSE.

<li>	SECTION A: CONTENTS PAGE [5pts]<br>
	(a) A table of contents of document.
	<br>
	(b) A list of all the files in diskette.
	<br>
	(c) Name of program modules and
	the PERSON(s) responsible for each module,
	<br>
	(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. 
	And NOTHING ELSE. 

<li>	SECTION B: PROJECT OVERVIEW [10 pts]<br>
	B.1. Introduction: this is up to you.<br>
	B.2. The object of the game:
		this can be modified from your proposal.<br>
	B.3. The user view of the game:<br>
		this can be modified from your proposal.<br>
	B.4. Highlight any interesting or special achievements.

<li>   SECTION C: USER INSTRUCTIONS [10 pts]<br>
	C.1. How to install game (including requirements).<br>
	C.2. How to execute your program and play game.<br>
		Include instructions for quick
		EXIT from the game (typing ESCAPE, for instance [-4pts].
	C.3. Any features or hints for users to know about.
		Tell the user of possible problems here.

<li>	SECTION D: TECHNICAL PORTION [10 pts]<br>
	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:
	<ul>
	<li> which graphics mode and any special graphic effects,
	<li> music and sound effects,
	<li> mouse programming,
	<li> interrupt programming,
	<li> use of randomness,
	<li> use of the timer or other ports,
	<li> keyboard programming, 
	<li> recursive procedures,
	<li> memory management (chap.14, including .com),
	</ul>
	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.

<li>	SECTION E: CONCLUSION [5 pts]<br>
	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.
	
<li>   APPENDIX I: ORIGINAL ASSIGNMENT [2 pts]<br>
	Just a copy of this document.
<li>	APPENDIX II: ORIGINAL PROPOSAL [2 pts]<br>
	Attache any any approved modifications as well.
<li>	APPENDIX III: COMPLETE GAME PROGRAM [5 pts]<br>
	Copy of well-commented programs.
	Each file should begin on a new page with the
	name of the file at the first line.
	If you have 5 files, say,
	then you will have subsections III.1, III.2,..., III.5. 
<li>	APPENDIX IV: ORIGINAL SOURCES [-100 pts]<br>
	Copy of any programs that are not your own, that you
	have used 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.
</OL>
Each section must begin with a new page.
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).

<p>
<b>ITEM 2: DISKETTE</b>
<p>
The second item in the envelop is a 3.5'' diskette containing
the following information and files [20 pts].

<OL>
	<li> Label on diskette with class identification,
		your team names and project name [-4 pts].
	<li> A file called README.TXT [10 pts].
		This can be
		the COVER PAGE and SECTIONS A and B of your report above.
	<li> The main module MUST be in a file called GAME.ASM.
	<li> There is a macro library (from hw4) called MYMAC.LIB [4pts].
		Of course, we expect you to use this library
		whenever possible.
	<li> I want you to break up the game into several modules [6pts].
		All the module name should begin with the letter `G'.
		E.g., the modules might be
		<pre>
		GAME.ASM, G_GRAFIX.ASM, G_SOUND.ASM, G_INPUT.ASM
		</pre>
		that corresponds to the main module, graphics
		sound, and input for the game, etc.
		Each module must belong to a team member
		who has the <b>primary</b> responsibility for it.
		The initial comments for the module should give
		this information.
	<li>   An executable called GAME.EXE must be present [-10pts].
	<li>   A bat file called ASM.BAT to assemble your game [2pts].
		For instance, if your files are as in the
		above example, then the ASM.BAT file might look like this:
		<pre>
		TASM GAME + G_GRAFIX + G_SOUND + G_INPUT
		TLINK GAME + G_GRAFIX + G_SOUND + G_INPUT
		</pre>
		This file is for us, as well as for your own use.
		(For your own debugging, you might want to
		write another file DB.BAT which calls TASM
		with /zi, /z flags, etc, and calling
		the turbo debugger TD.)
	<li>  A bat file called GO.BAT which calls your GAME.EXE [2pts].
		For most students,
		the GO.BAT file simple contains the line "GAME.EXE".
		But if your game needs to load the TSR program RANDOM.COM
		which we provide, then your GO.BAT file might contain
		the lines
		<pre>
		RANDOM.COM
		GAME.EXE
		</pre>
		Some other games might have even more fancy setup.
	<li> If you have used programs or substantial fragments
		of code from other sources,  please put them
		all under a subdirectory called SOURCES [-80pts].
	<li> If your game requires data files, or will produce
		files, please put them all under a subdirectory
		called DATA [-4pts].  But files should be explained in
		the CONTENTS SECTION of the REPORT.
	<li> NO UNRELATED FILES may be on your disk [-10pts].
		If you like, you can have a subdirectory
		called OTHERS, and put everything else there.
		E.g., hw1.asm, etc, should be in OTHERS.
</OL>

<h3><font color=aa0000>
GRADING
</font></h3>

Besides the points already allocated for the above
items, we allocate the following points:

<ol>
<li> 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 errors.
In view of this, I suggest that you take our
suggestion to initially focus your effort on the
``basic game''.
<li>
Online documentation [20 pts]:
what we mean is that when I execute your
program, I will get an initial introduction
to your game (its name, its objectives, and how to
play it).  This can be as simple as
printing a page of instructions at the beginning
of the game.
<li>
We allocate up to 30 points for additional game features
beyond your basic game.  Be sure to tell us about them!
<li>
We allocate up to 20 points for making the game
more user friendly.  For example:
	<ul>
	<li> You allow me to have a quick but graceful
	exit from the game (without having to
	power down!).  Or, I can
	get out from a long musical preliminary (which
	is nice but...).
	<li> You give me several levels of playing ability.
	<li> You ask me if I want to play the game again,
	before quitting.
	<li> You restore the original video mode
	after quitting the game.
	</ul>
<li>
Comments and Inline documentation within the files [25 pts].
We 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. 
</ol>

<h3><font color=aa0000>
NOTES
</font></h3>

<ol>
<li> 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.
<li><b>Instructions are strict:</b>
	It is hard to believe, but I had students
	who do not submit proposals and are in no team.
	At the last moment they hand me a
	diskette (from a team of one).  
	This guarantees an automatic 0 for the project.
<li><b>Code re-use:</b>
	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.
	<br>
	First, you should take over a major piece of code,
	do some minor changes to it, and claim it is your
	own.  This is very serious <b>plagiarism</b> and
	a university disciplinary problem.
	<br>
	Second, never use a piece of code without
	fully understanding it yourself.
<li><b>Debugging:</b>
	re-read debugging instructions from our FAQs page.
	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 (but put them in the
	subdirectory OTHERS), in case you want
	to modify your procedures later!
</ol>

<!--
<h3><font color=aa0000>
APPENDIX (subsequent information)
</font></h3>

<ol>
<li>
</ol>
-->

</body>
</html>

@
