Teaching
670 S '07
 
Projects
Presentations
Programming
 
Squadron Scramble
Aircrafts
Project 1
Project 2
Project 3
Project 4
Project 5
Project 6
Project 7
Project 8
Project 9
Project 10
Project 11
Project 12
Project 13

Project 12

Due date: 4/09 : 6pm

Maintenance

As promised, software doesn't exist in a vacuum. Customers change their minds; rule designers alter their games. Software developers have no choice but to follow their customers and adapt their software to the new conditions.

In our case, the rules of Squadron Scramble are changing. Specifically, the game designers have decided that players can exchange wildcards from discarded squadrons. If a player discards any squadron using a wildcard (or two), then during a later turn any player who has a corresponding aircraft card in his possession may exchange the aircraft card for one of the wildcards.

For this rule interpret "discard" as "discarded fighter or bomber squadron" or a "fighter squadron used to attack some bomber squadron". Once a bomber squadron with wildcards is shot down, the wildcards are lost for the rest of the battle.

Task 1: [POINTS: 15] Design changes to the interfaces, classes/modules, contracts, cheating detectors, and unit tests. Use class diagrams, sequence diagrams, interface statements with contracts, and prose to describe those pieces.

Task 2: [POINTS: 10] Implement a "tracer bullet" (see "The Pragmatic Programmer") version of your design.

Note: What you have so far in your svn repository is "tracer bullet" code. [BTW, the analogy isn't just violent, it's also broken---at least for someone like me, who has served in the military and shot machine guns.] It demonstrates the working of the entire game system, end to end, for both sides of the coin ("dealer" and "player"). It is missing some functionality, but it's right on target.

This part of the assignment suggests that you extend your "tracer bullet" code to design without forgetting to create the design. Put differently, consider parts 1 and 2 of the project as co-dependent, even though you can do them separately and even though you are to deliver distinct products.

Recall from your readings in "Pragmatic Programmer" that "tracer bullet" code evolves into the "real thing" but that portions of it could go wrong. You must be prepared to back out of portions of your project, and this is a warning that this specific piece of code could be just one of those.

Task 3: [POINTS: 5] Revise the XML-based protocol from Project 10 for testing your new interaction routines.


last updated on Tue Jun 9 22:03:19 EDT 2009generated with PLT Scheme