Travel Software for Kids for Laptop or PDA -Final Report-

Team May04-14

Client Senior Design

Faculty Advisor Doug Jacobson

Team Members Jonathan Soike Nick Ransom Jonathan Gill Mike Mundy

April 6th, 2004 Table of Contents List of Figures...... ii List of Tables...... iii List of Definitions...... iv 1. Introductory Materials...... 1 1.1 Executive Summary...... 1 1.2 Acknowledgement...... 2 1.3 Problem Statement...... 2 1.4 Operating Environment...... 2 1.5 Intended Users and Uses...... 2 1.6 Assumptions and Limitations...... 3 1.7 Expected end product and other deliverables...... 3 2. Project Approach and Results...... 4 2.1 Functional Requirements...... 4 2.2 Design Requirements...... 4 2.3 Approaches Considered...... 4 2.4 Detailed Design...... 6 2.5 Implementation Process...... 17 2.6 Testing...... 17 2.7 End Results...... 17 3. Resources and Schedules...... 18 3.1 Resources...... 18 3.2 Schedules...... 20 4. Closure Materials...... 24 4.1 Project Evaluation...... 24 4.2 Commercialization...... 24 4.3 Recommendations for Additional Work...... 25 4.4 Lessons Learned...... 26 4.5 Risk and Risk Management...... 27 4.6 Project Team Information...... 28 4.7 Closing Summary...... 29 4.8 References...... 29 4.9 Appendices...... 30

i List of Figures

Figure 2.1: Travel bingo game example screenshot...... 8 Figure 2.2: Travel bingo game flowchart...... 9 Figure 2.3: License plate finder example screenshot...... 10 Figure 2.4: License plate finder flowchart...... 11 Figure 2.5: Travel board game example screenshot...... 14 Figure 2.6: Travel board game startup screen flowchart...... 15 Figure 2.7: Travel board game single turn of game play flowchart...... 16 Figure 3.1: Original, revised, and actual project schedule, part 1...... 21 Figure 3.2: Original, revised, and actual project schedule, part 2...... 22 Figure 3.3: Deliverables Schedule...... 23

ii List of Tables Table 2.1: Programming languages...... 5 Table 2.2: Development tools...... 5 Table 2.3: Installation software...... 5 Table 2.4: 2D art software...... 6 Table 3.1: Original estimated personnel effort requirements...... 18 Table 3.2: Revised estimated personnel effort requirements...... 18 Table 3.3: Actual personnel effort requirements...... 18 Table 3.4: Original estimated other required resources...... 19 Table 3.5: Revised estimated other required resources...... 19 Table 3.6: Actual required resources...... 19 Table 3.7: Original estimates project costs...... 19 Table 3.8: Revised estimated project costs...... 20 Table 3.9: Actual project costs...... 20 Table 4.1: Production Costs...... 25

iii List of Definitions

API: Application program interface.

Game engine: A game engine is a software application that handles all fundamental elements needed to develop a game. These elements include but are not limited to: graphics, physics calculations, sound, and tools to interact with these systems.

GUI: Graphical user interface. A non-text-based display used for user interaction.

OS: Operating system of a computer.

Source code: Source code is the non-compiled version of a program

iv 1. Introductory Materials

1.1 Executive Summary

1.1.1 About the Project The goal of this project was to create an educational, travel-themed software package for children aged 4 to 12 to play on a laptop computer during car trips. This would enable parents to entertain their children in a car without resorting to more mindless forms of entertainment, such as videos or DVDs. The software was designed to be easily played in a moving vehicle by children with limited motor skills.

1.1.2 Project Activities To fulfill the project requirements, three travel-themed children’s games were developed: a License Plate Finder, Travel Bingo, and a Travel Board Game.

The License Plate Finder is a simple program that lets children track which license plates they have spotted on the road. By displaying the license plates on a map, the game helps children learn U.S. Geography.

Travel Bingo is game similar to regular Bingo, except road signs and other things seen from a car are used instead of numbers. The game can be played by up to four players. Squares can be randomly generated by the computer, or players can use things they see out the window.

The Travel Board Game is a simple board game played by up to four players. Players take turns rolling dice, moving the rolled number of squares, and following the instructions on those squares. For each square moved, one gallon of gas is drained. In order to keep advancing, players must refill their gas tanks at gas station squares. To successfully purchase gas, the player must determine how much they can afford based on the current gas price. This helps children practice their math skills.

1.1.3 Final Results At the end of the project, all three games were completed successfully. However, some originally planned features, such as an interface tying the games together, and child-protection schemes, were not implemented. Still, the project goals were met.

1.1.4 Recommendations for Follow-on Work The games themselves are complete and require no additional work. However, there are two ways the project could be enhanced.

1 1. Additional games. Since the final product contains only three games, children may become bored with them. Were the product to contain a wider variety of games, the life of the product would be extended.

2. A main interface for the games. This was included in the original design, but was not completed. The games could be tied together by a kid-friendly interface that would make it easy for the child to choose the games they want to play, and allow them to switch between them. The interface should also include protection schemes that lock the child out of the rest of the computer, ensuring that they don’t damage parents’ data.

1.2 Acknowledgement The team would like to acknowledge the project advisor, Dr. Doug Jacobson, for being the main source of help throughout this project. The team would also like to acknowledge Andre LaMothe, author of Tricks of the Windows Game Programming Gurus, for providing a great deal of help with DirectX coding.

1.3 Problem Statement General problem statement: Overall the program is directed towards 4-12 year old boys and girls that need something to do during a road-trip.

General solution approach: The program includes three games: License Plate Finder, Travel Bingo, and a Travel Board Game. These games are simple enough to be enjoyed by children within the specified age range, and can be played in a moving vehicle without much hassle.

1.4 Operating Environment These games are to be used in a moving vehicle, possibly in stop-and-go conditions, and possibly at continuous speed. The game’s environment on the computer is expected to be Windows 98+ compatible.

1.5 Intended Users and Uses Intended users: The intended users will be children with the following attributes:  Ages 4-12  Pre-school to 7th grade  Both male and female  Previous computer experience

Intended use: The intended use is for these children to play these games on a laptop while in a moving vehicle.

2 1.6 Assumptions and Limitations

1.6.1 Assumptions  Children playing these games should have previous computer experience.  3 games have been developed.

1.6.2 Limitations  The maximum number of players shall be 4.  The minimum number of players shall be 1.  Children playing these games should be between the ages of 4 and 12.  The end product runs on Windows 98+ operating systems.  The product operates on laptop computers.

1.7 Expected end product and other deliverables The game The end product is the package of games that the team produces.

Project plan This is the initial plan on developing the software for this particular problem. It includes the frontal materials (title page, table of contents, etc.), introductory materials, the proposed approach and statement of work, the estimated resources and schedules, and the closure materials.

Source code The source code is the non-compiled version of the games to be made. This includes detailed lists of variables used and function headers that explain what each function does.

Users’ manual The users’ manual describes in a non-technical language how to install and configure the program, how to use controls, and how to play all the games.

3 2. Project Approach and Results

2.1 Functional Requirements The following list describes the required functionality of the program. The following requirements are geared toward the interests of both the children playing and parent(s) driving in the vehicle.

 Should have bright colors – Studies have shown that bright colors help to hold children’s attention for longer periods of time  GUI components selected by mouse should be large – Motor skills of smaller children are not as developed. Furthermore, mouse components on many laptops are hard to use.  Should contain both single and multiplayer games – Having single and multiplayer games allow for different types of family structures, i.e. number of children.  Games should be for ages 4-12 – Specified in project description.  Should not make loud sounds – Loud sounds can potentially distract the driver and will inevitably annoy parents.

2.2 Design Requirements  Must run on Windows 98 and greater  Must run on a Pentium 100MHz or greater  Must require no more than 650MB of hard disk space  Program must use no more than 32MB of RAM  Simple interface  Simple game rules

2.3 Approaches Considered These are the factors that the team considered to develop the software in an optimal environment.

2.3.1 Constraints considerations  Operating system – Must run on Windows 98 or later  Hardware – laptops running on a Pentium 100MHz or greater  Program size – Must fit onto one CD-ROM

4 2.3.2 Technology considerations

Tables 2.1 through 2.4 list the languages and software considered for use on the project. Each table compares the advantages and disadvantages of each. Table 2.1: Programming languages Advantages Disadvantages C The team is already familiar with it. Not object-oriented, not very well supported by Windows. C++ Object-oriented, well supported by GUIs are more difficult than other Windows, the team is already languages. familiar with it, there are many information resources for it. C# Object-oriented, has built-in GUI The team has never used it. components. Java Object-oriented, has built-in, but The team isn’t as familiar with it as limited, GUI components. other languages, difficult setup and running procedures on end user’s machine.

Table 2.2: Development tools Advantages Disadvantages Visual Studio Free for students, has many Licensing issues may prevent useful features, well supported. end-product sale. Borland C++ Free for student/individual use. Not as well supported or featured as Visual Studio. DirectX Fast, Windows-compliant, well- Difficult to code, large learning Libraries documented, hardware curve. independent. Kyra Libraries Platform independent, easier to Slower than DirectX. code than DirectX, provides several useful development tools.

Table 2.3: Installation software Advantages Disadvantages InstallShield Included with Visual Studio, The team will have to learn how easy installation for end user. to use it. Batch files Simple, easy for the team to “ Messy” installation, potentially implement. confusing for end-users

5 Table 2.4: 2D art software Advantages Disadvantages PaintShop Pro Free trial version, has many Full version is expensive, features. not many information resources. Adobe Fully featured, has many Very expensive. Photoshop information resources. The GIMP Open source, several features Not as many features as and information resources. commercial programs.

2.3.3 Consideration Results The team decided to go with the following technology options:  Programming language: C++ was chosen because its object-oriented nature lends itself well to game programming. Also, since the entire team is familiar with it, less time will be required to learn how to program the games.  Development software: Visual Studio was chosen because it is the best C++ development environment, and is free. Travel Bingo was coded with DirectX, and the game engine Kyra was used for the License Plate Finder and the Travel Board Game.  Installation software: InstallShield was chosen since it is packaged with Visual Studio, and makes the installation simple for the end-user.  2D art software: The GIMP was chosen because the project’s budget doesn’t accommodate commercial versions of the alternatives. Its features are also sufficient for the project.

2.4 Detailed Design This section describes the design of the games to be implemented. Each description has three parts. The first section describes the game rules. This section is broken into four parts: number of players, objective, rules, and controls. Second is an example screenshot. It gives a sample of what the completed game will look like. The third part is the game flowchart. Read from top to bottom, they describe the “flow” of the game, with each possible path branching out as appropriate

6 2.4.1 Travel Bingo Number of Players: 1-4

Objective: Get 5 signs in a row (vertically, horizontally, diagonally)

Rules/How to play: The game is played in the same format as traditional bingo. At the start of the game, select whether the game is to be played on screen or off. Off screen Packaged with the game are laminated Travel Bingo cards. Click start when the computer is to start generating the signs. Click ‘next’ when a new sign is needed. Click BINGO when someone yells out BINGO! The game will end.

On screen Enter the number of players to play and their names. Then select if the computer is to generate the road signs, or if signs will be used as seen by the players on the road. Click start. Whenever the player locates an item on their card, they mark the card on the screen. After all cards have been marked, click ‘next’. If there is a BINGO, the computer will notify.

Controls: Mouse, keyboard

7 Figure 2.1: Travel bingo game example screenshot

8 Figure 2.2: Travel bingo game flowchart

9 2.4.2 License Plate Finder Number of Players: Infinite

Objective: Find license plates, record who found them

Rules/How to play: Players look for license plates on cars on the road, click the corresponding state, and enter the name of the person who found it.

Controls: Mouse, keyboard

Figure 2.3: License plate finder example screenshot

10 Figure 2.4: License plate finder flowchart

11 2.4.3 Travel Board Game: Number of Players: 1-4 w/ computer players

Objective: Get to the end first

Rules/How to play: Computer will randomly decide who goes first. First player clicks “Roll dice”. Player piece will be moved that number of spaces. Follow instructions on game board space.

Doubles If a player rolls doubles, they can roll again. If doubles are rolled three times in a row, the player is caught speeding, taken back to the nearest sheriffs station, fined $10, and loses one turn.

Money Every player starts out with $50 at the beginning of the trip. The money is used for gas or fines incurred throughout the game. Should the player land on an expense space where they do not have enough money to cover the expense, the player will lose a turn, while waiting for a relative to wire them more money. The relative will wire the player the remaining balance of the fine and an additional $50.

Gas Each player has a gas tank holding twenty gallons for their car. The car starts out with a full tank and loses one gallon of gas in the tank for every place moved on the board in a forward direction. (NOTE: being sent back does not use gas, only forward direction does). If the user passes a gas station space, the user has the option to stop at the gas station or to continue on with the number rolled. If the user should decide to fill up with gas, after filling the tank, the turn is over.

Filling up the gas tank When the player decides to fill up the gas tank, the player will be informed how much money they have, how much gas they need, and how much gas is per gallon. The player will be asked how much gas they wish to buy. If the player enters an amount of gas which is more than the gas tank can hold or costs more than the player can afford, the player will be informed and asked again. Should the player enter an invalid amount again, the player will be given hints as to how much gas the player should purchase.

12 Running out of gas Should a player run out of gas between gas stations, the player will be towed back to the last gas station, and fill up on gas. Should the player not have enough money to pay for a full tank of gas, the player will be prompted if they wish to lose one turn waiting for a relative to wire them enough money to fill up their tank or to purchase a smaller amount of gas (NOTE: Player may not have enough gas to make it to next gas station).

Board Spaces Lose a turn These spaces cost the player one turn.

Lose money These spaces take money away from the player.

Gain money These spaces give money to the player.

Go back These spaces send the player back a specified number of spaces.

Go forward These spaces send the player ahead a specified number of spaces.

Wildcard The player will draw a card, and be instructed to do whatever action specified on the card.

Controls: Keyboard, mouse

13 Figure 2.5: Travel board game example screenshot

14 Figure 2.6: Travel board game startup screen flowchart

15 Figure 2.7: Travel board game single turn of game play flowchart

16 2.5 Implementation Process The team agreed to split into groups to work on each game. Each group worked on their game independently until a working version was created. The working version was then given to the team members that were not in the group for feedback and testing. Necessary changes were made by the original group. The games were then given to testers for additional feedback and bug testing, and additional changes were made based on their suggestions. This process could be improved by consulting the outside members for feedback before a working version was finished. This way, bugs could be discovered earlier, and changes could be made more easily.

2.6 Testing Testing by team members was done informally. The members simply used the programs, and alerted the programmers of any bugs or needed changes they discovered. Testing was also performed by children of the target age group. The parents were asked to give the programs to their children, and evaluate the programs based on the following criteria: clarity of the game’s objective, the child’s ability to operate the game, and much the child enjoyed the game. The parents were also asked to report any bugs they encountered, and to suggest any changes they thought would improve the games. A sample test form can be found in Appendix A.

2.7 End Results At the end of the project, all three games were completed as specified by the design document, and were tested by both team members and outside sources. In the process of coding the project, all team members did their own research into creating graphics with C++.

17 3. Resources and Schedules

3.1 Resources This section describes the estimated and actual effort requirements, resource requirements, and project costs both with and without labor. It also includes estimated and actual project schedules.

3.1.1 Personnel Effort Requirements The original and revised estimates were pretty close together, since the team wasn’t entirely sure how tasks would be divided up. However, as work on the project continued, roles for each team member became clearer, and the actual time spent on each task by each member began to deviate from the estimate. Table 3.1: Original estimated personnel effort requirements Project Plan Project Design Final Personnel Testing Totals Name and Poster Design Implementation Report John Soike 20 30 60 15 15 140 John Gill 20 30 60 15 15 140 Nick Ransom 20 30 60 15 15 140 Mike Mundy 20 30 60 15 15 140 Totals 80 120 240 60 60 560

Table 3.2: Revised estimated personnel effort requirements Project Plan Project Design Final Personnel Testing Totals Name and Poster Design Implementation Report Jonathan Soike 17 35 70 10 5 137 Jonathan Gill 18 35 65 10 20 148 Nick Ransom 23 25 55 20 15 138 Mike Mundy 22 25 50 20 20 137 Totals 80 120 240 60 60 560

Table 3.3: Actual personnel effort requirements Project Plan Project Design Final Personnel Testing Totals Name and Poster Design Implementation Report Jonathan Soike 17 35 80 10 5 147 Jonathan Gill 18 30 75 10 10 143 Nick Ransom 23 30 45 20 20 138 Mike Mundy 22 25 40 25 5 117 Totals 80 120 240 65 40 545

18 3.1.2 Other Required Resources Since the project is mostly software, no major expenditures were required. Some allowances for various materials were made in the estimates, but were ultimately not used. Table 3.4: Original estimated other required resources Parts and Materials Team Hours Other Hours Cost a. CD-R's 0 0 $15.00 b. Project poster 12 0 $45.00 Table 3.5: Revised estimated other required resources Parts and Materials Team Hours Other Hours Cost a. CD-R's 0 0 $15.00 b. Project poster 12 0 $45.00 c. Laminated bingo cards 5 0 $25.00 Table 3.6: Actual required resources Parts and Materials Team Hours Other Hours Cost a. Project poster 12 0 $45.00

3.1.3 Project Costs Again, because this was a software project, there were few outside costs. As such, the only differences between the estimated costs and the actual costs were due to labor, and materials that were ultimately unused. Table 3.7: Original estimates project costs Item W/O Labor With Labor Parts and Materials: a. CD-R's $15.00 $15.00 b. Project poster $45.00 $45.00 Subtotal $60.00 $60.00

Labor at $10.50 per hour: a. Soike, John $1,470.00 b. Gill, John $1,470.00 c. Ransom, Nick $1,470.00 d. Mundy, Mike $1,470.00 Subtotal $5,880.00 Total $60.00 $5,940.00

19 Table 3.8: Revised estimated project costs

Item W/O Labor With Labor Parts and Materials: a. CD-R's $15.00 $15.00 b. Project poster $45.00 $45.00 c. Laminated bingo cards $25.00 $25.00 Subtotal $85.00 $85.00

Labor at $10.50 per hour: a. Soike, Jonathan $1,438.50 b. Gill, Jonathan $1,554.00 c. Ransom, Nick $1,449.00 d. Mundy, Mike $1,438.50 Subtotal $5,880.00 Total $85.00 $5,965.00

Table 3.9: Actual project costs Item W/O Labor With Labor Parts and Materials: a. Project poster $45.00 $45.00 Subtotal $45.00 $45.00

Labor at $10.50 per hour: a. Soike, John $1,543.50 b. Gill, John $1,501.50 c. Ransom, Nick $1,449.00 d. Mundy, Mike $1,228.50 Subtotal $5,722.50 Total $45.00 $5,767.50

3.2 Schedules This section shows the project work and deliverables schedules. The project schedule contains three entries for every task. First is the original estimate, second is the revised estimate, and third is the actual result. The deliverables schedule has remained constant since the start of the project, and therefore has just one entry for each task.

20 Figure 3.1: Original, revised, and actual project schedule, part 1

21 Figure 3.2: Original, revised, and actual project schedule, part 2

22 Figure 3.3: Deliverables Schedule

23 4. Closure Materials

4.1 Project Evaluation This section contains a list of the milestones set forth in the original project plan, and evaluates them based on the following scale: Greatly exceeded, exceeded, met, almost met, partially met, didn’t meet, didn’t attempt.

1. Problem definition: Exceeded. The team determined exactly what the problem was, and created a solution based on the intended users and the intended uses. 2. Research: Met. All team members learned how to program using the Windows API. 3. Technology selection: Partially met. Though tools for completing the project were successfully chosen, the tools used by each team member varied, and therefore no “best” technology was chosen. 4. Concept design: Met. Every aspect of each game was fully designed before the coding process began. 5. End-product design: Didn’t attempt. No formal code design was planned. Code was written and tested “on the fly.” 6. Prototype implementation: Met. Working prototypes were created, which were given to team members for testing. 7. End-product testing: Met. The end-product was thoroughly tested for bugs, and all discovered bugs were eliminated. 8. End-product documentation: Met. A users’ manual was created which detailed how to play each game, and the source code was well commented. 9. Project reviews: Almost met. Although the end-product was tested by members of the target age group, more tests done by a wider range of ages would have been helpful. 10.Project reporting: Met. All necessary documents were completed, and all weekly reports were sent. 11.End-product demonstration: Unknown. As of this writing, the product demonstration has not occurred. This document will be updated after the demonstration.

Overall, the project was a success. Most milestones were met, and those that weren’t met didn’t significantly harm the end-product.

4.2 Commercialization The project was developed using free/open source development tools. Therefore, commercialization of the project would be fairly cheap. However, some art used in the project (such as the license plate images) may be copyrighted. Those issues would need to be resolved before any commercialization could take place.

24 4.2.1 Cost of Production Assuming the above copyright issues were resolved, production of the product could be done very cheaply. A commercial package would contain the following products: Table 4.1: Production Costs Item Approximate Cost CD $0.30 Jewel case $0.20 User’s manual $0.10

Therefore, a commercial package could be produced for around $0.60.

4.2.2 Selling Price Many simple children’s games can be purchased for $5.00 to $10.00. However, since this project cost nothing to create, and since it is of lower quality than most commercial packages, it could be sold for $1.00 to $2.00 and still be profitable.

4.2.3 Potential Market This product would be marketed toward parents who wish to entertain their children in the car. Therefore, the product would sell best in children’s stores, toy stores, and the like. It could also be placed in the children’s or budget sections of software stores.

4.3 Recommendations for Additional Work The games themselves are complete and require no additional work. However, there are two ways the project could be enhanced.

1. Additional games. Since the final product contains only three games, children may become bored with them. Were the product to contain a wider variety of games, the life of the product would be extended.

2. A main interface for the games. This was included in the original design, but was not completed. The games could be tied together by a kid-friendly interface that would make it easy for the child to choose the games they want to play, and allow them to switch between them. The interface could also include protection schemes that lock the child out of the rest of the computer, ensuring that they don’t damage parents’ data.

25 4.4 Lessons Learned

4.4.1 What went well  The design process. All team members had ideas for the final product, and good amount of debate and refinements went into choosing the final design. The final design incorporated ideas from all team members, and was appropriate for solving the problems defined in the project plan.

4.4.2 What didn’t go well  The coding process. Since none of the team members had any experience coding graphics, the team first had to learn how to do it before the coding could begin. Therefore, coding didn’t begin until well into the second half of the schedule. As a result, the coding process was rushed, and the quality of the final product wasn’t as high as originally anticipated.  Communication between team members. Through much of the second half of the project, team members weren’t entirely aware of what other members were doing at the time. Thus, some minor duplicate work was done, and there was some confusion as to which members were to do which jobs.

4.4.3 Technical Knowledge Gained  Microsoft Visual Studios. Microsoft’s Visual Studios suite, both version 6 and .NET, were used to code the project. Team members gained experience with these development tools, which will make future programming projects much easier.  C++ graphics coding. As mentioned before, at the start of the project, none of the team members had any experience coding graphics in C++. In creating this project, the team learned the basics of creating 2D graphics in C++, both with game development engines, and without.

4.4.4 Non-technical Knowledge Gained  Group programming experience. Though all team members had experience coding in groups, none had programmed a group project this large. Each team member refined his group programming skills and is better prepared for future group programming projects.  Project scheduling. The team learned how to create a project schedule using Microsoft Project, and also learned the importance of sticking to that schedule.

4.4.5 What to do differently  Begin graphics research earlier. Had the team learned how to code graphics with C++ during the first half of the project, coding would have begun on schedule in the second half, and the final product would have been higher quality.

26  Increase communication between team members. It’s important that all team members know what the other members are doing at any given time. Therefore, whenever a member begins or completes work on any part of the product, it would be helpful to send an e-mail or some other notification to the rest of the team.  Put more emphasis on the schedule. Parts of the project weren’t necessarily started when the schedule said they should be, nor were they always done in the planned order. In the future, sticking more closely to the schedule would help ensure that all team members were aware of what was going on, and what needed to happen in the future.

4.5 Risk and Risk Management

4.5.1 Anticipated Potential Risks This section lists possible risks the team considered in the project plan, as well as techniques for minimizing these risks.  Loss of team member – To minimize this risk, all team members were made aware of each others’ tasks and roles, to assume and distribute those tasks should this event occur.  Loss of data/code – All data was backed up in multiple sites, on multiple systems.  Over-proposed project – To minimize this risk, the faculty advisor was consulted before the final design was submitted.  Kids do not like games – Children’s games were researched before game concepts were designed. If children do not like the game prototypes, the team will attempt to revise games to incorporate their suggestions in the final version.

4.5.2 Anticipated Risks Encountered This section lists which anticipated risks listed above were encountered, and how they were handled.  Over-proposed project – Though the faculty advisor was consulted before the final design was completed, there were still more features than the team was able to implement in the time given. To ensure that the project could still be considered successful, the team devoted attention to the more important aspects of the project.

4.5.3 Unanticipated Risks Encountered This section lists encountered risks which were not anticipated in the project plan, and details how those risks were handled.  Incompatibility of development software. It was discovered that code compiled with Visual Studios .NET would not run on machines without certain library files included with .NET. To cope with this risk, the necessary libraries were included with the final product.

27 4.5.4 Resultant Changes in Risk Management This section lists the changes made in the team’s risk management strategy due to the encountered risks.  Test software on different systems. Due to the incompatibility issue, developed software was tested on a variety of systems, including systems without the development software installed.

4.6 Project Team Information Name: Doug Jacobson Mailing Address: 2419 Coover Hall, Ames, IA, 50010 Telephone number: (515)-294-8307 Email Address: [email protected] Advisor

Name: Jonathan Gill Mailing Address: 139 Sheldon Ave #6, Ames, IA 50014 Telephone number: (515)-231-6816 Email Address: [email protected] CprE

Name: Nick Ransom Mailing Address: 4226 Frederiksen Court Telephone number: (515)-572-7860, Ames, IA 50010 Email Address: [email protected] CprE

Name: Mike Mundy Mailing Address: 2721 Ferndale Ave. #4, Ames, IA 50010 Telephone number: (515)-663-8784 Email Address: [email protected] CprE

Name: Jonathan Soike Mailing Address: 922 Duff. Ave, Ames, IA 50010 Telephone number: (515)-203-0207 Email Address: [email protected] CprE

28 4.7 Closing Summary Entertaining children during car trips is a problem that faces nearly every family today. Car companies have begun addressing this problem by including TVs and DVD players in newer cars. The goal of this project was to create a cheaper and more educational solution to that problem. To this end, three educational, travel- themed games were created. These games should help entertain children during car trips while simultaneously improving their math and geography knowledge.

4.8 References Bingo game background provided by www.randmcnally.com Bingo icons provided by www.iconbazaar.com Base DirectX code provided by Tricks of the Windows Game Programming Gurus by Andre LaMothe

29 4.9 Appendices

4.9.1 Appendix A: Sample Test Document Tester’s Information: Age: ____ Gender: ( M / F ) Previous Computer Experience: None-----Barely any-----Some-----A lot

In the following questions, please grade each category on a scale from 0 (worst) to 5 (best). Please use the back of this page for any specific comments, questions, or concerns.

License Plate Finder: Clarity of objective: 0-----1-----2-----3-----4-----5 Ease of use: 0-----1-----2-----3-----4-----5 Entertainment: 0-----1-----2-----3-----4-----5

Travel Bingo: Clarity of objective: 0-----1-----2-----3-----4-----5 Ease of use: 0-----1-----2-----3-----4-----5 Entertainment: 0-----1-----2-----3-----4-----5

Travel Board Game: Clarity of objective: 0-----1-----2-----3-----4-----5 Ease of use: 0-----1-----2-----3-----4-----5 Entertainment: 0-----1-----2-----3-----4-----5

Use the area below to report any bugs or program errors you encounter, as well as any problems you encounter with the installation program. Be sure to include the game and the conditions under which the problem occurred, and any error messages that are displayed. Be as specific as possible. Use additional pages if necessary.

30