Little Johnny has Cirrhosis
by Team Florida Orange Juice
Weekly Meetings:
Tue 10:30-11:00am @ AP/M 3313
Class Lab:
AP/M 3313, Code: 0533855
Development Tools:
- Visual Studio .NET for development
- WinCVS for project source control
- Maya for 3D modelling
- Adobe Photoshop 7.0 for texture generation
- Cool Edit for sound effects
API's and File Formats:
- OpenGL for 3D Graphics
- DirectPlay for networking
- BASS library for sounds (based on DirectSound)
- Quake 2 .MD2 files for 3D models
- JPEGs for textures
- MP3s for background music
Testing
As the individual modules are developed, each will be thoroughly tested through the use of debugging, logging, profiling, & memory checking utilities. Once each module is determined to be stable, it will be integrated into the overall project at which point it will be everyone's responsibility to verify overall stability & performance.
Communication and Decision Making
We will be using a group messageboard as our primary means of communication. Whenever possible, we'll use the messageboard to discuss & reach a consensus regarding each major design decision. When a consensus is not possible, we'll use polls/voting to determine the most popular solution.
Documentation, Progress Reports, and Scheduling.
Documentation will be maintained individually by each group member & recorded in the "progress reports" section of this website. Ideally, each member will make detailed reports of what he has completed at the end of each day. Then, at the end of each week these reports will be compiled into a single team report. No single teammember will always be responsible for generating these reports - we will take turns depending on who is the busiest at a given time. These progress reports can then be used to clearly determine who's ahead of schedule, who's behind, etc, so that we can re-allocate tasks between teammembers in an effort to stick to our schedule.
For code documentation, we will try to contain as much code in individual modules, each with clearly documented "header" files so that we can minimize excessive writeup. Where such summaries are not possible, or where the code is excessively complicated, we will use detailed internal inline commenting so that the operation can be understood from the code alone.
Website by Andrew Strauss and Justin Klein (2004)