1 - Iowa State University



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

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

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

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

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. 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.

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.

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

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 Windows, the team is |GUIs are more difficult than other languages. |

| |already familiar with it, there are many information | |

| |resources for it. | |

|C# |Object-oriented, has built-in GUI components. |The team has never used it. |

|Java |Object-oriented, has built-in, but limited, GUI components. |The team isn’t as familiar with it as 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 useful features, well |Licensing issues may prevent end-product sale. |

| |supported. | |

|Borland C++ |Free for student/individual use. |Not as well supported or featured as Visual Studio. |

|DirectX Libraries |Fast, Windows-compliant, well-documented, hardware |Difficult to code, large learning curve. |

| |independent. | |

|Kyra Libraries |Platform independent, easier to code than DirectX, |Slower than DirectX. |

| |provides several useful development tools. | |

Table 2.3: Installation software

| |Advantages |Disadvantages |

|InstallShield |Included with Visual Studio, easy installation for end|The team will have to learn how to use it. |

| |user. | |

|Batch files |Simple, easy for the team to implement. |“Messy” installation, potentially confusing for |

| | |end-users |

Table 2.4: 2D art software

| |Advantages |Disadvantages |

|PaintShop Pro |Free trial version, has many features. |Full version is expensive, not many |

| | |information resources. |

|Adobe Photoshop |Fully featured, has many information resources. |Very expensive. |

|The GIMP |Open source, several features and information resources.|Not as many features as 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

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

Figure 2.1: Travel bingo game example screenshot

Figure 2.2: Travel bingo game flowchart

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

[pic]

Figure 2.4: License plate finder flowchart

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.

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

Figure 2.5: Travel board game example screenshot

Figure 2.6: Travel board game startup screen flowchart

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

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++.

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

|Personnel Name |Project Plan and |Project Design |Design Implementation |Testing |Final Report|Totals |

| |Poster | | | | | |

|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

|Personnel Name |Project Plan and |Project Design |Design Implementation |Testing |Final Report|Totals |

| |Poster | | | | | |

|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

|Personnel Name |Project Plan and |Project Design |Design Implementation |Testing |Final Report|Totals |

| |Poster | | | | | |

|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 |

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 |5 |0 |$25.00 |

|cards | | | |

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 |

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.

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

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

Figure 3.3: Deliverables Schedule

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.

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.

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.

• 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.

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: dougj@iastate.edu

Advisor

Name: Jonathan Gill

Mailing Address: 139 Sheldon Ave #6, Ames, IA 50014

Telephone number: (515)-231-6816

Email Address: jgill@iastate.edu

CprE

Name: Nick Ransom

Mailing Address: 4226 Frederiksen Court

Telephone number: (515)-572-7860, Ames, IA 50010

Email Address: rannic@iastate.edu

CprE

Name: Mike Mundy

Mailing Address: 2721 Ferndale Ave. #4, Ames, IA 50010

Telephone number: (515)-663-8784

Email Address: MikeMundyISU@

CprE

Name: Jonathan Soike

Mailing Address: 922 Duff. Ave, Ames, IA 50010

Telephone number: (515)-203-0207

Email Address: jsoike@iastate.edu

CprE

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

Bingo icons provided by

Base DirectX code provided by Tricks of the Windows Game Programming Gurus by Andre LaMothe

4.9 Appendices

4.9.1 Appendix A: Sample Test Document

Tester’s Information:

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:

Travel Bingo:

Travel Board Game:

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.

-----------------------

Age: ____

Gender: ( M / F )

Previous Computer Experience: None-----Barely any-----Some-----A lot

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

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

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

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download