| Return to CIS 300. |
|
For this lab you will learn how to start working in your groups together. In particular, you will learn how to use CVS, and you will learn how to develop architecture together.
All parts of this lab should be done with the other members of your group. In particular, in submitting the architecture document, there should be only one submission from each group.
The very first thing that you should do as a group is figure out how to use CVS. Your group has been assigned the CVS project cis300gX where X is your group number. Look at the groups page to determine your group number.
The first thing you should do is to read the CVS resources page to learn how to use CVS in CSUG. Once you have done that you should call over a TA and demonstrate that you know how to use CVS by demonstrating the following steps:
There is nothing to turn in for this part of the lab. You will be given pass/fail credit for your demonstration to the TA during the lab.
Architecture design is harder than it looks. Many of you have only constructed very simple programs, or else the program architecture was already presented as part of the assignment and you just had to create the code. You have to do more than that here.
For this lab, you will construct a simple architecture document. Your architecture document will be for the Flash version of Portal. Imagine that you are porting this game to XNA. We are not expecting you to program the game; we simply want you to architect it.
Your architecture document should consist of the following.
For this part of the class, a subsystem is just a significant part of the game that a single programmer could work on in isolation, provided that the programmer has an API of the other subsystems. For example, AI is a subsystem that can be programmed distinct from the rest of the code. While it needs to know the methods of the enemy units, it does not need access to their source code.
It is important to identify subsystems because they are the ways in which you can divide up work among your group members. Therefore, you should identify a minimum of three different subsystems.
Provide a high-level (bullet points are fine) overview of what type of information needs to be passed between the subsystems. For example, if you had networking, the UI subsystem needs to send the IP address to the network subsystem in order for it to connect with the server.
Design interfaces (methods and properties) for these communication points only. Do not make interfaces for anything inside a subsystem that is not exposed. For example, if you had a networking layer, you do not need to identify every single class used in networking. Likewise, in the simulation subsystem (e.g part of the code that occurs in the Update() method that is specific to the game, but which may or may not include physics or other general purpose libraries), you do not need to outline the classes for every enemy or terrain obstacle. You should only expose the functionality needed to communicate between the systems.
As a general rule, each subsystem should have only one interface. However, if any subsystem needs to pass complex information to another system (e.g. AI subsystem passes a movement path to the simulation/update subsystem), you may need to present a class for that. However, you do not need to construct a class for anything that you can commonly find in an object oriented programming language (e.g. Points and Rectangles).
For each method in each interface that you outlined above, give a brief explanation of how its removal would affect the other subsystems. In addition, identify ways in which you could alter (but not remove) this method without affecting other subsystems.
Submit a file called "architecture" to CMS. This file may either be a text file (txt), a Microsoft Word file (doc), or a PDF file (pdf). Once again, there is nothing to turn in for the CVS assignment.
Due Wednesday February 20, 2008 at 11:59pm