Overall Project Organization

We use the first 9 weeks of the term for design and construction of projects. Week 10 is reserved for final presentations. A more complete schedule is available.

We will begin with all teams working on a common project that will be due at the end of week 4. That's a very tight schedule, and I will encourage you to scope it appropriately and approach it incrementally, to minimize the risk of not having something good to turn in at the deadline. Project scoping and risk control are core Software Engineering skills

You will have the option of switching to another project of your own choosing (with my approval) in week 5, but I encourage you to at least strongly consider making a second iteration of the same project.

Project 1 Overview

The Game Rules Reader

Background

Learning the rules for a new game can present challenges, particularly for computer and multi-player role-playing games (RPG). The rules for these games are complex and may, additionally, require significant understanding of certain aspects of networking and other computer technology. Communicating game information including such things as installation, networked play, character building, in-play rules, and so on becomes a balancing act. For the experienced RPG player, very little information may be needed. For the novice ("n00b") there is likely to be a significant learning curve requiring detailed explanations of many aspects of the game. A rule book suitable for the novice is likely to be tedious and difficult to use for the expert. Conversely, a rule book designed for experts is likely to leave a novice bewildered. We would like to be able to help readers with a variety of skill levels and purposes learn game rules by providing a reader that supports learning and even adapts to the needs of different kinds of readers.

Example Scenario

T. Rex is an expert gamer who has been playing massively-multiplayer RPGs for several years. He's recently purchased a new RPG, the Dragon's Revenge that supports both individual and on-line play. He would like to get up to speed on the game quickly be reading the back story and aspects of character creation and game play that are unique to this game.

An example of a typical set of RPG rules can be downloaded here. For this prototype, you should do something simpler (e.g., a smaller game or a subset of the rules).

Basic Requirements

The Game Rules Reader (GRR) provides an engine for presenting game rules (and associated information) to an individual on a computer screen. Minimally, the GRR should provide the capabilities of a basic hyper-text document reader such as:

• Present the current "page" of a hyper-text manual
• Allow paging, scrolling, and other standard navigation between pages
• Support hyperlinks from one part of the document to another
• Support highlighting text
• Support writing and attaching notes to the text
• Support minimal customizing of the presentation**

**The basic GRR should support simple customizing of the reading experience. The person writing the rules (we'll call a "Writer") can indicate at least two classes of users. The Writer can then designate whether any given part of the document will or will not appear for the indicated class of user.

Creative Opportunities

The GRR is a wide open platform for possible improvements. While many different kinds of improvements are possible for any kind of document reader, we are particularly interested in creating readers that will allow a Writer to choose different presentation strategies for different classes of users. For example, one that would give a novice user a narrative or instructional presentation of the rules at any desired level of detail. Conversely, give the experienced user a shortened version focusing on differences from common practice in RPG games. Teams may want to consider or even add simple features along these lines for the first version of the GRR.

For teams wishing to extend the GRR in the second half of the course, such improvements may also be considered then. This project is the suggestion of Prof Steve Fickas and related to our CampusReader project that focuses on developing a reader for science textbooks (i.e., treating science as a rule-based game). The project is particularly interested in textbook readers who have reading comprehension issues (some studies put this at 25% of the college population). The CampusReader project can employ strategies that assess a reader's understanding. Consider how you might test a player's understanding of game rules. Self-test questions at end? Vocabulary quiz? Match game screenshots to text descriptions?

Project 2

Teams have the opportunity of either continuing to enhance the Game Rules Reader or to do a project of their own choosing. The options are described in more detail below. For either option, you should plan or presenting a written proposal to the instructor in the form of a draft Concept of Operations.

Game Rules Reader II

The objective of the second version of the GRR will be to move from a passive reader to an application that actively engages the reader to improve attention, comprehension, or understanding. Where GRR1 required the reader to choose how the rules would be presented, GRR2 may actively assess the reader's capabilities and adjust its presentation accordingly. Examples of such capabilities include:

• Comprehension Assessment: the reader provides capabilities to actively assess the readers comprehension. A simple form of this would be to provide a set of multiple choice questions along with or at the end of document sections. The tool keeps track of the scores and adjusts the presentation accordingly. A more complex form might actually present game scenarios and ask what the reader would do or ask the reader to do something like construct a character and assess the result. A killer capability in this area would be to generate possible questions based on content.
• Note Sharing: Support the sharing of notes between readers. Readers have the option of seeing the notes from other people who have read the same document.
• Performance Based Adaptation: The way the rules are presented are linked to the reader's actual experience and performance in game tutorials or the game itself. As the reader's performance stats demonstrates mastery of the game as a whole or particular facets of the game, the reader adjusts the presentation of the rules accordingly. A simple version of this might link character level or levels of the game passed to levels of expertise. A more complex approach might look at specific accomplishments within the game.
• Social Learning: Reading and understanding the game rules becomes a social-learning experience. The reader is linked live with a social network of others who are reading the rules or are otherwise interested in the game play. The reader is able to ask questions, read posts, and otherwise interact with people who are also learning the rules or who have experience applying the rules in game play.
• Other ideas?

Other requirements:

Version 2 of the reader should provide a high-quality user experience. Where this has not already been done, the reader will need to be revised to provide a full set of navigation controls and well-formatted "pages" that are easy to read. We will define a complete set of these requirements for GRR2.

Team-Chosen Project

Your team may elect to do a project of your own choosing. A good project idea will include:

• An interesting idea for an application.
• Enough complexity that the project needs to be effectively modularized and developed concurrently among team members.
• Enough different capabilities that the project can be sensibly divided into increments. Each increment should represent a useful subset of the application capabilities so the team will have something to turn in even if every feature cannot be completed.
• Small enough scope that a complete set of development artifacts (project plan, ConOps, SRS, Architecture Specification, etc.) can be develped in addition to the code artifacts

Proposals for an team-chosen project should be implemented in two stages: First, come up with brief descriptions of two or three possible project concepts and discuss these with the instructor to choose a project to pursue. Second, create a written proposal for the project in the form of a draft ConOps.