CSE 490CSW Course Description

Spring 1998

Course Mechanics

The course goals are (in roughly decreasing order of importance):

1. To learn about the software design process through hands-on development of a software product.
2. To experience working in larger teams than you have had to deal with previously in our curriculum.
3. To experience building sophisticated applications by making use of real-world tools (e.g., the DirectX SDK), rather than trying to build everything from scratch.
4. To gain experience dealing with the performance demands of high-performance, real-time, distributed applications.
5. To have some fun.
6. To develop a portfolio documenting your efforts that could be useful in looking for a job.

Note that there is a key distinction between a "software product" and "software". This is elaborated upon in the next section.

The project is intentionally only very vaguely specified.

You are to build a distributed, real-time, 3D, multiplayer game. (Note:  Your team can decide to build something other than a game, but should discuss specific suggestions with us.)  The nature of the game is up to you: it can be an action game, a strategy game, or a roll-playing game. (It must include the buzzword characteristics listed above, though.) Developing specifications for the game is intended to be both part of the fun and part of the design experience.

You should imagine that you are a small company. What you can achieve is limited by the amount of resource you can put into the product; in this case, this means primarily the time frame over which you must produce the product (10 weeks) and the amount of personpower you can put into its development. You should not be too aggressive in your specification because of the costs associated with completing the project, and the risks of cost overruns or outright failure. On the other hand, you can't afford to be too conservative, because your product must compete in the marketplace.

To succeed, you have to use a combination of brawn and brains. By brawn, I mean basically hard work: how many hours you put in. By brains, I mean working creatively and efficiently. There is far greater leverage in brains than brawn, and you should use it to maximum advantage. In a competitive environment, both are necessary.

To work efficiently you need tools. The more powerful they are, the more you can do. Because your goal is to produce a software product (meaning software that meets the specification functionally and that is maintainable (to maximize future efficiency), and supporting documentation), you should make use of tools that help you. Among these are existing packages that provide functionality you will need, tools that help manage the software, and tools that help you produce and maintain documentation. (I'm leaving out all considerations of marketing here, as these won't come into play in our limited exercise.)

The tools we have in mind, described elsewhere, are DirectX (for handling multimedia functions and perhaps communications), Java, Microsoft's Visual Studio, a 3D modelling package (e.g., Rhino3D), and other more familiar tools (like word processors, source control systems, etc.). However, a major part of your job is to decide which tools to use, including which (if any) to build yourself. Obviously, you are somewhat limited here by your budget (i.e., we don't have the funds to purchase everything available, or even any one thing that is very expensive). You can request that we provide software not already loaded on our systems, but realistically in the time we have it's unlikely that you will be able to identify and make a case for other products from among the huge number out there.

There is only one assignment ("produce your product") and no exams. However, there are a number of checkpoints that require you to turn things in. Here is the schedule:

All the work above is to be done as a team.  Each team is expected to produce weekly "status reports" that explain what has been accomplished during the past week, what was expected to be accomplished but wasn't (and why), what is scheduled for the coming week, and an update of the full project schedule.

The only lecture currently scheduled is during the first meeting:

There may be some other guest lectures during the quarter.

Starting April 2, the instructor and TA will meet each Thursday during class time with each team.

Grading will be based largely on group performance. However, we expect to get to know what each of you has done individually through the weekly meetings with the groups, and some adjustments will be made on that basis.

Additionally, we may institute other procedures for self- or mutual evaluation within groups.

Sometimes group members can't get along. Severe problems can be symptomatic of bad project management, or they can be caused by non-cooperative or non-performing individuals.

If your group is having significant problems, get in touch with us.

You will have to deal with two severe performance issues: how much you can get done in 10 weeks, and how much the machine can do in 100 msec. (corresponding to a frame rate of 10 fps, which is minimal for reasonably smooth motion).

One way to deal with how much you can do is to design a development schedule that gets something usable up quickly and then adds features as time permits. It would be wise to shoot for minimal functionality after no more than two to three weeks (into the development cycle). Do not try to pull this project off by working individually for six weeks to produce bug-free full-function code and assuming that integration will be a snap.

Regarding machine performance, the major cost is going to be rendering. While it may be easy (ha!) to write code using the DirectX SDK that will, functionally, render very complicated scenes, your frame rate is likely to be abysmal. Major determinants of rendering cost are the number of polygons in the scene and the number of pixels to be rendered. Keep polygon count low. Don't count on being able to run in a full-screen sized window.