Mathematics and Computer Science Department    

CS 326   Object-Oriented Design,   Fall 2003,  Instructor:  Jeffrey Horn


ANNOUNCEMENTS (Sunday, December 7, 2003, as of 4:30 pm)


LINKS


CONTENTS


LECTURE NOTES

 


INDIVIDUAL WORK    (HOMEWORKS & PROGRAMS)

TEAM WORK

  • FINAL PROJECT
  • Assigned:  Monday, December 1, 2003
  • Due:  Monday, December 8, 2003 at the final exam!  (10 am)
  • Here are the teams and their assignments.
  • The basic tasks, common to all teams, are the following:
    1. Team designs a class hierarchy for their assigned functionality.
    2. Team documents class hierarchy in a UML class diagram.
    3. Team codes up at least one abstract class for the hierarchy.
    4. Individual implements one derived class of the abstract class.
    5. Team presents their results at the final exam on Monday, Dec. 8, 10am-12noon.
  • I will need the following to grade:
    1. UML class diagram.
    2. Working C++ code for the abstract class(es), and for all of the derived classes. 
    3. A working demonstration of all of the classes.  (i.e., a complete GS folder)
  • NEW:   (as of 12-7-03) 
  •  (Here is a direct link to the 3D GameStudio Manual) 
  • Here is some last minute guidance on the final project.  First, since our final is Monday, first day of finals, please concentrate on your presentation.  You can finish code and a UML diagram and turn them in later during Finals week. 
  • Your presentation will be short, say 10 minutes, and informal.  If you have a working demo, show it first.  (A working demo is a big plus in grading, but if you can get a working demo to me later in the week, I won't take off much.)  Then show a class diagram, even if you have only one class!  (You should try hard to come up with more.  Remember, you do not have to implement more than one of them!  Just think of related classes and sketch them out, in terms of member methods, public and protected.  For example, you might just barely get working a class that contains "ent_morph" functionality, allowing an entity to morph into another entity during the game.  Nice, but you might think of extensions of this class that would only allow morphing if it is to a similar type of entity (e.g., make sure the "scale" of the entities are similar, or that they are both humanoids, etc.).  )  Then we will grill you on how to use your class, and its methods, how it coul be extended, specialized, or generalized or whatever.  So all that is really important for Monday is that you show SOMETHING, preferably code (at least a header file with the method signatures) AND a class diagram so we can see how you've thought the class might fit into a family of related classes (for weather, particle, etc.).
  • NATURE OF THE TASK:  Recall that this course is on object oriented design.  For this final project, I want people to really put whatever they have learned or seen so far into a DESIGN of their own.  That is, I want people to be thinking of taking Cscript functions and making them available IN OBJECTS (classes):
    • You target users for your code are other C++ programmers, like me or your classmates in CS 326.  Assume we know C++, and a bit about 3D GameStudio, but not Cscript! 
    • Your job is to package some little piece of Cscript, like the ent_morph or ent_scan functions, and make them available to us in C++.  This means calling the Cscript functions from within C++ methods, which of course must be part of some class.  So look to the examples in BasicEntity, and think in terms of what would YOU want as a C++ programmer who wants to use something like ent_morph but who does NOT want to deal with any Cscript or DLL stuff, like getting a pointer to ent_morph (with the "getWDLfunction" DLL function), converting integers or floats to FIXEDPOINT, or converting pointers to LONG.  I just want to call some C++ method with standard C++ data types or objects. 
    • Think of BasicEntity from assignment 3.  This is what you are doing for this Final:  coming up with your own BasicEntity class.  Maybe it should be abstract, and there should be some abstract methods (i.e., "pure virtual functions" in C++ talk), in which case you should specify one derived concrete (non-abstract) class of it.  Or maybe the associations should be aggregation.  For example, for weather, suppose we create one class for rain, one for snow, etc., and then the Weather class has one object of each of these classes and then "activates" one or more at a time.  Or is it better for "Snow", "Rain", "Windy", "Thunder", to all extend the parent class "Weather"?  Should a "Sandstorm" and a "Snowstorm" extend the same base class?  I mean, they both blow around particles.  This is what I want people to think about and take a first shot at for Monday.  No one else has!  You'll be the first.  But it is important that you ground your design in some real Cscript functionality, preferably by actually implementing a part of your design, say a subclass or a few methods of a base class, in calls to Cscript function(s).   To help with this,  here is a direct link to the 3D GameStudio Manual (4MB compressed html file), if you don't have it already.
    • Example: 
      • Scanning by Entities:  There are a bunch of Cscript instructions (functions) like "ent_scan", "trace", and "content", that can be used  by an entity to look around and detect obstacles, or nearby entities, and get pointers to them, or find out the texture of a nearby entity.  How can we make these capabilities available to a BasicEntity?  Would I create an object of a class "Senses" and then be able to call a bunch of C++ methods that "wrap" the various Cscript functions? 
      • Sounds:  Cscript has instructions for reading in and playing sound files, in a loop or just once.  Should this be made available as an object that can be declared within another class?  Or should "Audible" be a superclass that gets extended by any class wishing to inherit the methods it has?  I don't know!  I want you to come with SOMETHING that I can then criticize!
    • This is a final.  Take it seriously.  Do all of the above tasks.  I will be flexible on when you hand them in.  But have something designed that we can discuss on Monday.


  • PROGRAMMING


    TESTS AND QUIZES